Whatever happened to the work on getting Mario Adventure working on the PowerPak?
Why does it even need the faster RAM to work anyway?
3gengames wrote:
Why does it even need the faster RAM to work anyway?
3gengames wrote:
Why does it even need the faster RAM to work anyway?
I thought for sure you would know.
Well....my file splitter just says this for further record:
Mirroring:Vert.
8K SRAM:Yes.
Mapper 4, MMC3.
Program banks: 16. 16KB each.
But then, CHR-ROM banks: 20. 8KB each. [Why 160K of ROM and not 256?]
Strange. Why would the SRAM need to be ANY different at all? Very weird. Above my technical knowledge.
3gengames wrote:
Why does it even need the faster RAM to work anyway?
What says it needs it?
The only guy who makes working repros of this game charges some extra money in order to buy a special RAM chip, IIRC.
tokumaru wrote:
The only guy who makes working repros of this game charges some extra money in order to buy a special RAM chip, IIRC.
<sniff> <sniff>
SCAAAAAAMMMMMM!!!
cpow wrote:
tokumaru wrote:
The only guy who makes working repros of this game charges some extra money in order to buy a special RAM chip, IIRC.
<sniff> <sniff>
SCAAAAAAMMMMMM!!!
Well why would it not work? I read something that SOUNDED like it said it switches the CHR-ROM into PRG-ROM, but I know that's BS.... Anyone put this on a cart and see what's up?
tokumaru wrote:
The only guy who makes working repros of this game charges some extra money in order to buy a special RAM chip, IIRC.
Apparently the nesproductions.com repro comes with a sony 15L (150ns) WRAM chip on it. Not sure how that compares to SMB3's WRAM or the powerpak off the top of my head. But the game works with that chip.
That just sounds stupid....lol. What in the world would case the WRAM to need to be upgraded at all? What feature on the NES can access the RAM that fast?
3gengames wrote:
What feature on the NES can access the RAM that fast?
The PPU.
A half-cycle time of 150 ns sounds like 3.3 MHz, which is just a tad over the PPU's fetch rate (half dot clock). Perhaps it's been hacked to use CHR RAM in order to get around the IRQ counter's limitation.
Frankly, I think all this could be solved if someone on this board were to just
buy one. Yeah, I know, people don't want to patronize alleged scammers, but sometimes there's no better way to catch them.
Most smb3 is 10L (100ns). So it doesn't sound like the ram has even been upgraded. I know someone that owns the game, what are you thinking could be done tepples? Use the wram as VRAM?
I'm still guessing here; I don't own a copy.
In that case, if the PRG RAM is slower than normal, it might be to work around the bug where writes to $E000-$FFFF also write to $6000-$7FFF due to the delay on /ROMSEL. Or it might be that a certain kind of RAM plays nicer with a battery backup circuit.
So could you have someone open it up and take pictures?
If I had one I would. Maybe the other PRG-ROM bit combos from my splitter are wonky because CHR-RAM is used for the rest of it. But even then, it says it doesn't use CHR-RAM, so how can the emulator know what to allow?
Should we just try mailing him and ask him what's up with it specifically?
WhatULive4 wrote:
http://nesdev.com/bbs/viewtopic.php?t=6018
Which has no end with details either.
And it also says it's CHR-RAM switched and doesn't use WRAM? I don't understand THAT....
Mario Adventure does some minor illegal stuff. It uses both sides of the pattern tables for 8x16 sprites, which breaks the MMC3 scanline counter and causes the status bar to move up and down during gameplay depending on which sprites are visible. Emulators weren't as good back then, so Dahrkdaiz didn't realize that it caused problems. Newer emulators do things more correctly, which shows the true effects of the hacks.
Someone would need to make a game-specific mapper that operates the scanline counter differently, so it would act like an older emulator.
As for the game not booting, no clue why there would be any problems. Just pad out the CHR to the nearest power of 2 with blank space if you need to. Should just be the same cartridge as Kirby's Adventure.
But they take MMC3 boards and just upgrade the RAM. I don't think MMC3 is the problem....
I hate hacks, especially ones that are good, heh.
Dwedit wrote:
Mario Adventure does some minor illegal stuff. It uses both sides of the pattern tables for 8x16 sprites, which breaks the MMC3 scanline counter and causes the status bar to move up and down during gameplay depending on which sprites are visible. Emulators weren't as good back then, so Dahrkdaiz didn't realize that it caused problems. Newer emulators do things more correctly, which shows the true effects of the hacks.
Someone would need to make a game-specific mapper that operates the scanline counter differently, so it would act like an older emulator.
As for the game not booting, no clue why there would be any problems. Just pad out the CHR to the nearest power of 2 with blank space if you need to. Should just be the same cartridge as Kirby's Adventure.
That's what we all thought, but somehow this guy manages to make repros of the game. I doubt he's making his own mapper...
I've heard he's messed around with the code a bit perhaps this is why. I've got a dump of his repro I'll have to patch my own copy and compare to see if this is indeed the case.
EDIT: the only difference was in the header bytes 5 and 6.
My patch: 14 42
dumped copy: 20 43
Now I realize that wouldn't make a difference in the rom images if you were to make a repro, but it could affect how the power pak does things? I'll have to check some more with where I got it.
Talking with @coinhaven at thenesdump.com apparently all you need to do is swap out the WRAM for the 150ns SRAM to get it working on a TSROM. No battery backing with that though, does the game actually make use of battery backed saves? It would seem it shouldn't in the spirit of the originals, but I've never played.
infiniteneslives wrote:
Talking with @coinhaven at thenesdump.com apparently all you need to do is swap out the WRAM for the 150ns SRAM to get it working on a TSROM. No battery backing with that though, does the game actually make use of battery backed saves? It would seem it shouldn't in the spirit of the originals, but I've never played.
I can confirm this as I have a working cart I made myself.
marvelus10 wrote:
infiniteneslives wrote:
Talking with @coinhaven at thenesdump.com apparently all you need to do is swap out the WRAM for the 150ns SRAM to get it working on a TSROM. No battery backing with that though, does the game actually make use of battery backed saves? It would seem it shouldn't in the spirit of the originals, but I've never played.
I can confirm this as I have a working cart I made myself.
Okay then that's all it is....would putting the sprite table inside WRAM make it need that? Although the SMB3 game engine puts it at $200-$2FF, and I doubt these hackers changed that...
Hackers did not change origin of sprite DMA. Still $02xx.
The game does save some things, like worlds completed and number of coins. I think it's about 3 bytes of save data.
Dwedit wrote:
Hackers did not change origin of sprite DMA. Still $02xx.
Well what else can the PPU do to WRAM them?
Dwedit wrote:
Hackers did not change origin of sprite DMA. Still $02xx.
The game does save some things, like worlds completed and number of coins. I think it's about 3 bytes of save data.
I just too a look at SMA's readme and it say this about saving:
Code:
Saving:
The game will save some of your progress as you go along. The game saves the following statuses:
Coins
Score
Time
All Items
Item Box
Kuribo Shoe Storage
Worlds Completed
Keys Gotten
Locks Unlocked
So it sounds like it would be best to put it on a TKROM board then. I guess you could always battery back it yourself on a TSROM.
But it sounds like the guys making these repros don't even bother with battery save.
I think and don't quote me on this, remember before changing out the WRAM that it did not work at all on a TKROM board. But worked with audio out of sync and accelerated then froze on a TSROM board. So when the WRAM swap was sugested I just planted it on a TSROM board and all was good. I never did go back and try the TKROM board. Maybe sometime this week I will try it out if I get a chance. It would make senseif you wanted to take advantage of the save feature.
Im currently using a NES-TSROM-03 board with MMC3A
So is it possible the game shoves sound samples into the WRAM?
marvelus10 wrote:
It would make senseif you wanted to take advantage of the save feature.
I'm not holding my breath for anything to make sense with this one based on what we've concluded thus far. But yeah i'd like to see if it works on the TKROM.
It's highly likely though that the WRAM timing wasn't exactly the same between the TKROM and TSROM boards you had before you went to slow RAM. So hopefully that's the only reason why.
If it doesn't work let me know. I've traced through, and have a full schematic for TSROM and could do the same for TKROM. I don't know of any actual differences except battery backing. But if there are differences I'll figure out how to convert the TKROM to a TSROM with battery back.
3gengames wrote:
So is it possible the game shoves sound samples into the WRAM?
Very few mappers can map RAM into CPU $C000-$FFF1, the usable range that channel 5 can address. I've never seen the MMC3 do that.*
* Except in the case of a RAM-based copier that I own, which doesn't really count because the RAM used for PRG ROM data is write-protected by the time the game starts.
Oh, okay. I've never done sound, let alone DPCM or whatever it is, so I didn't know you had to use the last 16K [8K?] of space.
I can confirm that this will work on a NES-TKROM-01 board with MMC3B chip and transplanted faster WRAM.
Save progress works automatically and can be erased by Select+Up choose A or B.
marvelus10 wrote:
I can confirm that this will work on a NES-TKROM-01 board with MMC3B chip and transplanted faster WRAM.
Save progress works automatically and can be erased by Select+Up choose A or B.
Faster? Do you mean slower? the 10L chips already in the cart are 100nsec, and from what I understand it's the 15L sram you need to get it to work (150nsec)
Did you try it with the RAM on cart? What were your "symptoms?"
3gengames wrote:
Did you try it with the RAM on cart? What were your "symptoms?"
Black screen with accelerated messed up sound.
Wouldn't this be just a simple mapper hack to adjust the timing for the WRAM, then changing the info in the header to match the mapper hack so the PowerPak would recognise it?
You could rename it MAD-ROM-01 in the header then name your hacked TK-ROM accordingly.
Edit second thought:
Why if this works on emulators does it not work on the PowerPak? I thought the PowerPak was the same in the fact its was just a mapper emulator running on real hardware.
I assume I'm obviously wrong here because we would have 100% compatibility, seen as most emulators can run all Mappers.
Pad the rom before testing it on the powerpak.
Well if somebody knew what timing problems it had somebody could fix it.
And iNES doesn't have mapper names inside the header, only the values, but I'm sure you could assign it your own mapper for testing.
And does the powerpak have the same black screen accelerated sound problem or does it not play at all? I dunno, I guess padding it would help though.
So where might I find a sony 15L SRAM to modify TSROM board to play Mario Adventure?
I don't think any modification is needed, you just need to make sure the initial content of the RAM isn't bad.
How do you go about doing that?
1) You can get a different SRAM chip, which initializes the memory to 0 (which is probably what all these "faster" RAM chips did)
2) Or you can grab an IPS patch
here that should fix the RAM initialization issue. Further on in the same thread there's another patch that can be directly applied to SMB3 ROM.