Page 7 of 7

Posted: Sun Sep 17, 2006 12:18 am
by Bregalad
How would an emulator know how you wired up your 64KB RAM?
Effectivly, you're right, there is plenty different ways of wiring it. I think the 3 lowest bits of CHR selection would logically be used, but since BanditKings of Ancient China uses the upper bit to select between both 8kb chips, this makes much less sense. I'm unsure of this, but the lowest bit is forced to be used on the 4kb CHRRAM bankswitching (that nobody uses exept the crazy Lagrange Point), so we'd either cut that track, or use the 3 upper bits of CHR Bankswitching. That's quite confusing.

Kevtris : About the VS games, I'm unsure of what exactly they are, but doesn't they belong to the arcade category ? Anyway, you seem to have more knowledge about that, so I'm confident you can found a good support them.
Thanks for telling me what games has weird saving system.
About the sub-mappers, I really don't think they're needed, at least not for MMC1.
Since the new format support SRAM sizes, a game with 8kb batteried and 8kb unbatteried would mean a SOROM board (Bandit kings of Ancient China), and a game with 512kb of PRGROM would mean a SUROM board (Dragon Warrior III-IV; Dragon Quest IV). I don't see much problems with that. There is also Final Fantasy I&II (both on one cartridge, not the separate games) wich uses 16kb SRAM (all batteried) and also 512kb of PRGROM.

Posted: Sun Sep 17, 2006 12:51 am
by Memblers
Bregalad wrote: About the sub-mappers, I really don't think they're needed, at least not for MMC1.
It's a good point, but it seems a little hacky to do memory size checks to determine the board type. I'm not an emu author though.

Personally, I'd like to see a header say what revision the mapper is. If it's gonna describe the mapper, might as well be detailed. It's possible for a program written for one revision to not work on another (I've experienced that problem myself). Maybe that's what causes problems with "The Money Game". If we don't know all the differences now, the bit will always be there for when we do.

Posted: Sun Sep 17, 2006 1:42 am
by blargg
I second this idea of storing mapper revision information. The problem is, how do we determine the revision? When I was testing other boards a while back, I found two MMC3B chips manufactured just weeks apart that behaved differently. I didn't check the boards thoroughly for an external explanation, but it is still a possibility.

Posted: Sun Sep 17, 2006 11:38 am
by kevtris
Bregalad wrote: Kevtris : About the VS games, I'm unsure of what exactly they are, but doesn't they belong to the arcade category ? Anyway, you seem to have more knowledge about that, so I'm confident you can found a good support them.
Yeah they are arcade versions of NES games. Some are very interesting, like Vs. SMB. This is a MUCH MUCH harder version of SMB, and if you like SMB and haven't played the Vs. version, you really should. They removed almost all the powerups and 1-ups, except at the very start.
Thanks for telling me what games has weird saving system.
About the sub-mappers, I really don't think they're needed, at least not for MMC1.
Since the new format support SRAM sizes, a game with 8kb batteried and 8kb unbatteried would mean a SOROM board (Bandit kings of Ancient China), and a game with 512kb of PRGROM would mean a SUROM board (Dragon Warrior III-IV; Dragon Quest IV). I don't see much problems with that. There is also Final Fantasy I&II (both on one cartridge, not the separate games) wich uses 16kb SRAM (all batteried) and also 512kb of PRGROM.
Yeah I was thinking that too, but it's still kinda hacky. It's always good to have confirmation that yes, this really is an SOROM board. This breaks down for the Final Fantasy 1 and 2 multicart that Nintendo relased in Japan. This is a legit cartridge, and has 16K of WRAM and 512K of PRG ROM... and the bits used I think are different still. I don't have one of the carts so I cannot confirm.

But again, it's good to have a definite submapper set up for it. The submapper would be more useful to determine the type of MMC1 board we're dealing with.

* * *

I do like the idea of a way of telling an MMC1 or MMC3 revision also, but I'm not 100% sure how useful this would be from an emulation standpoint, and I'm sure many games were released with multiple MMCx revisions. As far as I know, only 1 game "cares" about this... that Japanese board game that does a funky scrolling thing by hitting the IRQ every scanline or something. I'm not sure what the game's name is right now.

Here's my big lists of mappers and stuff. NOTE: do not take this as the absolute gospel just yet... This is how mappers are allocated on the FPGA NES. Some of the assigned numbers are for "fixing" things such as mapper 16 (i.e. EEPROMs, WRAM, etc). So... those mapper numbers are "unofficial" and will go away if this V2.00 plan goes through. I adhered to FCEU's "fixup numbers" for the most part... but I'd really like to see all that go away by using the submapper thing.

http://tripoint.org/kevtris/cartz.txt

Please do not distribute this yet- again, it's very preliminary and I hope alot of the numbers will go away and stuff.

Posted: Sun Sep 17, 2006 12:35 pm
by Bregalad
Yeah I was thinking that too, but it's still kinda hacky. It's always good to have confirmation that yes, this really is an SOROM board. This breaks down for the Final Fantasy 1 and 2 multicart that Nintendo relased in Japan. This is a legit cartridge, and has 16K of WRAM and 512K of PRG ROM... and the bits used I think are different still. I don't have one of the carts so I cannot confirm.
I'm not sure what you mean by "hacky". A game wouldn't need a SUROM board to have 256kb PRGROM and leave the special bit unused, this makes no sense. This would be SNROM then. So I don't see anything hacky, the SUROM board is just a way that makes 512kb PRGROM possible on the MMC1.

Posted: Sun Sep 17, 2006 2:36 pm
by kevtris
Bregalad wrote:
Yeah I was thinking that too, but it's still kinda hacky. It's always good to have confirmation that yes, this really is an SOROM board. This breaks down for the Final Fantasy 1 and 2 multicart that Nintendo relased in Japan. This is a legit cartridge, and has 16K of WRAM and 512K of PRG ROM... and the bits used I think are different still. I don't have one of the carts so I cannot confirm.
I'm not sure what you mean by "hacky". A game wouldn't need a SUROM board to have 256kb PRGROM and leave the special bit unused, this makes no sense. This would be SNROM then. So I don't see anything hacky, the SUROM board is just a way that makes 512kb PRGROM possible on the MMC1.
Yes, but what if they use a different bit for the extra PRG bank select like they did on the FF1/FF2 cart in Japan? You cannot tell that strictly by ROM size, since both have 512K (DW3 or DW4 vs. this FF1/FF2 cart)

Posted: Sun Sep 17, 2006 3:32 pm
by tepples
kevtris wrote:Yeah they are arcade versions of NES games. Some are very interesting, like Vs. SMB. This is a MUCH MUCH harder version of SMB, and if you like SMB and haven't played the Vs. version, you really should.
You mean like Lost Levels hard, or Battletoads hard?

Posted: Sun Sep 17, 2006 4:04 pm
by Quietust
tepples wrote:
kevtris wrote:Yeah they are arcade versions of NES games. Some are very interesting, like Vs. SMB. This is a MUCH MUCH harder version of SMB, and if you like SMB and haven't played the Vs. version, you really should.
You mean like Lost Levels hard, or Battletoads hard?
Lost Levels hard would be an adequate description, as at least one level was taken directly from SMB2j (5-3 or 6-3, I think).

Posted: Sun Sep 17, 2006 8:09 pm
by Memblers
kevtris wrote: Yes, but what if they use a different bit for the extra PRG bank select like they did on the FF1/FF2 cart in Japan? You cannot tell that strictly by ROM size, since both have 512K (DW3 or DW4 vs. this FF1/FF2 cart)
I think he means it could also check the SRAM sizes (8kB battery versus 16kB battery in that case). Sounds like it'd work, but seems kinda indirect also. Like an implied sub-mapper.

Posted: Sun Sep 17, 2006 9:03 pm
by kevtris
Memblers wrote:
kevtris wrote: Yes, but what if they use a different bit for the extra PRG bank select like they did on the FF1/FF2 cart in Japan? You cannot tell that strictly by ROM size, since both have 512K (DW3 or DW4 vs. this FF1/FF2 cart)
I think he means it could also check the SRAM sizes (8kB battery versus 16kB battery in that case). Sounds like it'd work, but seems kinda indirect also. Like an implied sub-mapper.
Yep... it's kinda wishy-washy though. The submapper says exactly what to expect, whereas the RAM thing may not fully explain it. Again, I think having both at once would be the best option.

Posted: Mon Sep 18, 2006 12:35 am
by Bregalad
Yep... it's kinda wishy-washy though. The submapper says exactly what to expect, whereas the RAM thing may not fully explain it. Again, I think having both at once would be the best option.
Well, if you think so... But my opinion is that just sizes and mapper should tell everything about the cart content. Effectivly, the same bit doesn't have the same meaning, but on a given board with given PRGROM and SRAM sizes, each bit has always the same meaning, so I don't see anything hacky.
On the current iNES format, emus have to check the checksum or the rom's name to make the difference between DW4 and FF1&2.
Also, DW4 and FF1&2 uses the same bit for PRG bankswitching, it's just that FF1&2 uses another bit to select the SRAM chip than Bandit King of Ancient CHina. Emus that doesn't support FF1&2 proprely will think it's a SUROM cart with only 8kb SRAM, and they won't switch the SRAM. As a result, playing FF1 works fine as long as you don't touch FF2, but playing FF2 will totally overwrite FF1 saves, as far I know.
Since SRAM sizes are supported by the new format, I really see no need of submappers.

Posted: Mon Sep 18, 2006 12:54 am
by kevtris
Bregalad wrote:
Yep... it's kinda wishy-washy though. The submapper says exactly what to expect, whereas the RAM thing may not fully explain it. Again, I think having both at once would be the best option.
Well, if you think so... But my opinion is that just sizes and mapper should tell everything about the cart content. Effectivly, the same bit doesn't have the same meaning, but on a given board with given PRGROM and SRAM sizes, each bit has always the same meaning, so I don't see anything hacky.
On the current iNES format, emus have to check the checksum or the rom's name to make the difference between DW4 and FF1&2.
Also, DW4 and FF1&2 uses the same bit for PRG bankswitching, it's just that FF1&2 uses another bit to select the SRAM chip than Bandit King of Ancient CHina. Emus that doesn't support FF1&2 proprely will think it's a SUROM cart with only 8kb SRAM, and they won't switch the SRAM. As a result, playing FF1 works fine as long as you don't touch FF2, but playing FF2 will totally overwrite FF1 saves, as far I know.
Since SRAM sizes are supported by the new format, I really see no need of submappers.
Maybe for MMC1, but for other mappers they are absolutely required. A good example is the Bandai mapper 16 games with their various EEPROMs and such, and light pens and things... and mapper 83 which can have two different hookups for the CHR ROM, which results in 2 different CHR bank sizes. There's probably 10-20 mappers like this which have undetectable submappers (other than via CRC or similar).

Posted: Mon Sep 18, 2006 6:47 am
by mozz
Is it fair to say that you want a unique identifier for each hardware configuration (mapper chip plus wiring plus whatever else?). Other than memory size, which is represented already.

Mapper numbers were supposed to be this unique identifier, but it sounds like there are a handful of mapper numbers that were used for multiple different configurations.

Regardless of how we got in that situation, you don't want to re-map the conflicting ROMs to unique mapper numbers. (a) that breaks backward compatibility, and (b) there will always be old ROMs floating around out there.

So the idea is to add a sub-mapper number and use it to disambiguate those cases, which sounds pretty sensible to me.