It is currently Mon Nov 12, 2018 4:12 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next
Author Message
PostPosted: Tue Apr 03, 2018 6:57 pm 
Offline

Joined: Tue Mar 03, 2009 3:56 pm
Posts: 316
I installed these mappers and now when I try to play SMB1, it tries to start at World 0-1 instead of World 1-1

When I use mappers v1.12, v1.34 or Loopy's mappers, it loads fine. But once I install the power mappers it goes to 0-1


Top
 Profile  
 
PostPosted: Tue Apr 03, 2018 8:25 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20760
Location: NE Indiana, USA (NTSC)
Are you using a dump of an authentic copy of Super Mario Bros. or a bootleg extracted from a multicart? One of the common bootlegs is hacked to expect the multicart menu to pass it a world number, and you may get 0-1 if it isn't set properly.


Top
 Profile  
 
PostPosted: Tue Apr 03, 2018 8:55 pm 
Offline

Joined: Tue Mar 03, 2009 3:56 pm
Posts: 316
tepples wrote:
Are you using a dump of an authentic copy of Super Mario Bros. or a bootleg extracted from a multicart? One of the common bootlegs is hacked to expect the multicart menu to pass it a world number, and you may get 0-1 if it isn't set properly.


Hmm maybe that was the problem.. I got the powerpak second hand and the games were already loaded onto the flash card. I tried a different rom I had on my hard drive and that seems to work... though it's still pretty odd that all the old versions of the mappers worked with the original copy. I figured it was unlikely that the NROM mapper had any errors since it's the most basic one


Top
 Profile  
 
PostPosted: Tue Apr 03, 2018 9:27 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10957
Location: Rio de Janeiro - Brazil
Since the starting level in the hacked ROM is defined by the contents of RAM, the PowerPak menu is probably leaving different values in RAM depending on the mapper it loads. Are the mapper files temporarily stored in RAM when they're loaded into the FPGA?


Top
 Profile  
 
PostPosted: Tue Apr 03, 2018 10:08 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3676
Location: Mountain View, CA
Yeah, I was going to say, the PowerPak menuing system has gotta be at least partially responsible for this. Details: https://wiki.nesdev.com/w/index.php/PowerPak_Menu

It isn't the first time this has come up/affected something. It's pseudo-documented: https://wiki.nesdev.com/w/index.php/Pow ... imitations

It's one of the downsides to a menuing system that runs natively on the NES itself. I don't know the actual hardware specs for the PowerPak other than it's an FPGA, but honestly if the hardware was capable of it, it should really copy (back up) the contents of NES RAM to somewhere on the cart itself, then immediately before switching control over to a loaded ROM, restore NES RAM contents so that it's consistent.

I wouldn't be surprised if the copy of Super Mario Bros pre-loaded on frantik's PowerPak was some unofficial version (do you know how many versions of this game there are? It's literally crazy) that did something slightly different, utilising said RAM.


Top
 Profile  
 
PostPosted: Tue Apr 03, 2018 10:49 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10957
Location: Rio de Janeiro - Brazil
koitsu wrote:
it should really copy (back up) the contents of NES RAM to somewhere on the cart itself, then immediately before switching control over to a loaded ROM, restore NES RAM contents so that it's consistent.

I don't think this would be of much help to anyone, because even if the power up state of RAM is preserved, the rest of the state (CPU and PPU) is still gonna be destroyed. There have been a few cases of games that don't wait for the PPU to warm up running on the PowerPak but failing on standalone cartridges, so unless the devcart is able to retain the ROM contents and mapper configuration during a power cycle, it'll remain unreliable for testing boot up procedures.


Top
 Profile  
 
PostPosted: Tue Apr 03, 2018 11:29 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3676
Location: Mountain View, CA
I'm not sure I follow...

My concern isn't about "restoring RAM contents" on a power-cycle of the PowerPak; that would be roughly the equivalent to a save state. I'm not talking about that or anything close to that.

My concern is that the PowerPak's menuing system utilises RAM and ZP, which are then "tainted" prior to a ROM load+run. If a game -- there are several known (I think you and I both have been in threads discussing such) -- uses said RAM or ZP locations, it can end up misbehaving (compared to if the PowerPak wasn't involved (real game/cartridge used)). Thus, if the PowerPak had the ability to temporarily back up RAM and ZP somewhere **prior** to the menuing system being loaded, then later restore RAM/ZP immediately prior to ROM load+run, would it not solve this problem?

As for CPU and PPU state (of power-on and reset), those are known, but I don't understand how those would be relevant. Generally speaking almost all games operate off the assumption that several CPU flags, and the PPU state, is "effectively unknown" on reset/power-on, so they set them up themselves. Anyway, here's the known details (I believe blargg did most of the heavy lifting):

https://wiki.nesdev.com/w/index.php/CPU_power_up_state
https://wiki.nesdev.com/w/index.php/PPU_power_up_state


Top
 Profile  
 
PostPosted: Tue Apr 03, 2018 11:42 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6946
Location: Canada
Power-on RAM isn't really that reliable anyway. The only thing saving and restoring that would do is replicate its inconsistent behaviour, which is true to life at least.

...but all it would mean in this case is the hacked SMB will sometimes start up in different worlds.

The PowerPak loaders, on the other hand, leave it in some consistent, but not intentionally designed state (and part of that state might have to do with filenames and directory structure and other junk specific to your system).

I'm not really sure which is better. :P

It could also just initialize RAM to 00 or FF, but I don't know if that's particularly helpful either. It would probably make testing more consistent from system to system using the same PowerPak, at least? (Neither 00 nor FF will "work" with every game, depending on what you want to run, but the same is true for a system that has SRAM that powers up with an 00 or FF tendency. One or the other breaks.)

Could also use a RNG to initialize it, if you really want something that's inconsistent and might have a chance of flushing unwanted behaviours. While I think this is a good option for dev testing, I think it's actually a terrible option for general users.


Top
 Profile  
 
PostPosted: Wed Apr 04, 2018 12:07 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10957
Location: Rio de Janeiro - Brazil
koitsu wrote:
My concern isn't about "restoring RAM contents" on a power-cycle of the PowerPak; that would be roughly the equivalent to a save state. I'm not talking about that or anything close to that.

That's not what I meant. The power cycle I mentioned was meant to provide programs with a clean boot state, but that'd only be possible if the PowerPak could retain the previously loaded ROM and mapper configuration. It'd could then give control to the loaded ROM immediately on power on, without running menu software, accessing the CF card or configuring the FPGA. The PowerPak can't do this, of course.

Quote:
As for CPU and PPU state (of power-on and reset), those are known

Knowing them doesn't necessarily mean you can recreate them, like you can with the RAM. Like I mentioned before, the PPU has a boot up period, if you try to use certain registers or VRAM before the PPU is ready, it won't work correctly. This is why games are supposed to wait 2 or so frames before doing any PPU operations. When the PowerPak transfers control to the game, this warm-up period is long gone, so even games without wait loops will work fine, but will fail once they're put on standalone cartridges.

Quote:
but I don't understand how those would be relevant.

The PPU warm-up period is very relevant. As far as games running on the PowerPak are concerned, this period doesn't exist, and that may result in games with improper initialization routines.


Top
 Profile  
 
PostPosted: Wed Apr 04, 2018 1:01 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3676
Location: Mountain View, CA
rainwarrior wrote:
Power-on RAM isn't really that reliable anyway. The only thing saving and restoring that would do is replicate its inconsistent behaviour, which is true to life at least.

...but all it would mean in this case is the hacked SMB will sometimes start up in different worlds.

Right, and that's primarily my point (re: your first paragraph). I really don't see a downside, if it's possible. Do you?

Of course, if this can't be done with the PowerPak, then it's completely moot for me to even bring up (and then I'll feel like I was wasting everyone's time). All I know is that the Xilinx FPGA does in fact have some on-board or on-die RAM, since the PowerPak is advertised as having "extra graphics ram for four screen games and MMC5 exram". NES ZP/RAM is 2KBytes, and RAM for 4-screen games tends to be 2KBytes; MMC5 ExRAM is only 1KB. I don't know if the FPGA RAM for 4-screen games could temporarily be used as a storage buffer for (a copy of) NES ZP/RAM on power-on or not. I don't do FPGA stuff, nor do I have familiarity with the system.

rainwarrior wrote:
It could also just initialize RAM to 00 or FF, but I don't know if that's particularly helpful either. It would probably make testing more consistent from system to system using the same PowerPak, at least? (Neither 00 nor FF will "work" with every game, depending on what you want to run, but the same is true for a system that has SRAM that powers up with an 00 or FF tendency. One or the other breaks.)

The list of games that rely on ZP/RAM contents is always helpful. In general, for most it seems $00 (for all of ZP and RAM) is a good default, but not always. For others, $FF might seem like a good value, but not always. I think most notable are games that use ZP or RAM contents as a kind of "RNG seed".

It's remarkable how often this subject keeps coming up on the forum especially in recent days. Between the F-1 Race ordeal, then a discussion about Who Framed Roger Rabbit, and now this...


Top
 Profile  
 
PostPosted: Wed Apr 04, 2018 1:03 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3676
Location: Mountain View, CA
@tokumaru -- Okay, PPU warm-up period is a valid one. But the crux of what's getting discussed these days is ZP/RAM contents not "being true" to what the underlying hardware has on power-on (i.e. without a PowerPak involved). I'm focused on that since it's the subject that's bitten frantik and might be solvable.


Top
 Profile  
 
PostPosted: Wed Apr 04, 2018 1:27 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3135
Location: Tampere, Finland
PowerMappers clear most of the RAM (including PPU memories) to $FF before starting the game, that would explain the problem with the bad SMB ROM.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Wed Apr 04, 2018 1:30 am 
Offline

Joined: Tue Mar 03, 2009 3:56 pm
Posts: 316
I loaded up the rom into FECUXD and it also showed world 0-1. It looks like on the title screen the rom tries to load a value from $013E, which, if it's any value besides $5A, gets copied over into the memory address for the current world, which is offset by 1.. $00 means world 1, and $FF means world 0. FECUXD appears to set memory on power up in chunks of $00 and $FF, and it just happens $013E ends up as $FF, so it displays world 0-1. The game never initializes this area of memory. If you manually change $013E it to $00 then it loads world 1-1.

So what I'm guessing is happening is that the old mappers reset memory to $00 and the power mapper resets it to $FF (actually it looks like thefox confirmed this as I was typing this post). This ROM probably was the kind ripped from a multicart as tepples mentioned.. the file date is from 1996 so who knows. This does explain why the world select feature after beating the game never worked right though!


Top
 Profile  
 
PostPosted: Wed Apr 04, 2018 1:34 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 3135
Location: Tampere, Finland
frantik wrote:
So what I'm guessing is happening is that the old mappers reset memory to $00

Old mappers don't touch the memory at all, the contents are whatever happened to be left there by the menu.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: fo.aspekt.fi


Top
 Profile  
 
PostPosted: Wed Apr 04, 2018 2:00 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3676
Location: Mountain View, CA
frantik wrote:
I loaded up the rom into FECUXD and it also showed world 0-1. It looks like on the title screen the rom tries to load a value from $013E, which, if it's any value besides $5A, gets copied over into the memory address for the current world, which is offset by 1.. $00 means world 1, and $FF means world 0. FECUXD appears to set memory on power up in chunks of $00 and $FF, and it just happens $013E ends up as $FF, so it displays world 0-1. ...

rainwarrior described about 1.5 years ago what FCEUX does in its code: viewtopic.php?p=178159#p178159 . It also prompted him to send in a patch to allow the user to select what the behaviour should be: viewtopic.php?p=178170#p178170 . This isn't in FCEUX 2.2.3, but should be in the next version when it comes out (under Config -> RAM Init).

You can read the entire 7-page thread for interesting information all pertaining to this exact type of problem, and some others.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 79 posts ]  Go to page Previous  1, 2, 3, 4, 5, 6  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Ben Boldt, krzysiobal and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group