It is currently Sun May 26, 2019 2:43 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 75 posts ]  Go to page Previous  1, 2, 3, 4, 5
Author Message
PostPosted: Thu Jan 03, 2019 1:16 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8372
Location: Seattle
I don't know of anything—certainly a bunch of other thins already use the 8x8 attribute mode—but if you figure out what your implementation is missing I would greatly appreciate it if you'd share.


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 1:38 pm 
Offline

Joined: Fri Dec 08, 2017 5:12 pm
Posts: 32
zeroone wrote:
It looks like the SimCity prototype exposed some issues with Nintaco's MMC5 mapper. It works until you start playing. Then the displayed map area is garbled.

Does the prototype tap into some MMC5 feature not used by the other commercial games? Like the Wiki suggests, I probably just coded enough features to get the other MMC5 games working.

Not sure if it's the same issue you're having, but I had to disable the external attribute mode (palette and the address override) when not in frame to get the map working for MiSTer.


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 2:11 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 911
Location: New York, NY
GreyRogue wrote:
Not sure if it's the same issue you're having, but I had to disable the external attribute mode (palette and the address override) when not in frame to get the map working for MiSTer.


What's MiSTer?


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 2:29 pm 
Offline

Joined: Fri Dec 08, 2017 5:12 pm
Posts: 32
zeroone wrote:
GreyRogue wrote:
Not sure if it's the same issue you're having, but I had to disable the external attribute mode (palette and the address override) when not in frame to get the map working for MiSTer.


What's MiSTer?

https://github.com/MiSTer-devel/NES_MiSTer
https://github.com/MiSTer-devel/Main_MiSTer/wiki
My fork has a few more fixes I haven't pushed to the main repository yet, and SimCity works in it.


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 2:59 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 911
Location: New York, NY
Oh. It's an emulator. I thought MiSTer might have been some other MMC5 game I never heard of it.

This is a great opportunity for me to play with a new (to me) emulator though. Thanks for the link.


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 3:03 pm 
Offline

Joined: Fri Dec 08, 2017 5:12 pm
Posts: 32
zeroone wrote:
Oh. It's an emulator. I thought MiSTer might have been some other MMC5 game I never heard of it.

This is a great opportunity for me to play with a new (to me) emulator though. Thanks for the link.

Note that it's FPGA. The NES core requires the SDRAM board in addition to the DE10-Nano.


Top
 Profile  
 
PostPosted: Thu Jan 03, 2019 3:28 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 911
Location: New York, NY
GreyRogue wrote:
Note that it's FPGA. The NES core requires the SDRAM board in addition to the DE10-Nano.


:shock: So much for testing then.


Top
 Profile  
 
PostPosted: Sat Jan 05, 2019 11:41 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 911
Location: New York, NY
lidnariq wrote:
I don't know of anything—certainly a bunch of other thins already use the 8x8 attribute mode—but if you figure out what your implementation is missing I would greatly appreciate it if you'd share.


I think I found the issue in my MMC5 implementation. It's related to PRG RAM protection. Regarding registers $5102 and $5103, the wiki says, "to enable writing to PRG RAM, this must be set to ...". For some reason, I assumed that it also applied to reading from PRG RAM. After removing the apparently nonexistent read protection, the maps in Simcity are rendered correctly. Maybe we should rename the registers on the wiki to "PRG RAM Write Protect 1 and 2". I missed that detail.

Curiously, I never saw issues in other MMC5 games. Maybe those enabled PRG RAM write access near the start and never disabled it. Or maybe they treated it as read/write protect, like I thought it worked. Or maybe PRG RAM is used in parts of the game that I never played up to. Or maybe it's rarely used at all.


Last edited by zeroone on Sat Jan 05, 2019 12:53 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Jan 05, 2019 11:53 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 911
Location: New York, NY
By the way, is MMC5 WRAM nonvolatile? I noticed that you can save your city. Where does it go?


Top
 Profile  
 
PostPosted: Sat Jan 05, 2019 12:51 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8372
Location: Seattle
It's the standard ETROM behavior. I forget whether that means bank 4 or bank 0 is the one that's nonvolatile, though.


Top
 Profile  
 
PostPosted: Sat Jan 05, 2019 1:09 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 911
Location: New York, NY
lidnariq wrote:
It's the standard ETROM behavior. I forget whether that means bank 4 or bank 0 is the one that's nonvolatile, though.


I only see it reading and writing to banks 3 and 4 during gameplay and during save/load city. So, I'm leaning on bank 4. Is there a way to confirm this?

Edit: I see this note in the wiki:

Quote:
Until November 2018, it was thought that the MMC5 supported up to 2 PRG RAM chips, each up to 32KB in length. However, recent research found that bits 2-3 control state of two unknown pins which acts like A15-A16, allowing up to 128KB RAM support. Either or both chips may be battery-backed; 11 of the 15 MMC5 games include a battery.


I'll check the headers of the known MMC5 ROMs to see if 11 of them really are marked as having nonvolatile RAM. And if that's really the case, then I'll just save the contents of all the PRG RAM chips. This may have been improved with the new NES 2.0 header, but currently, there is nothing to indicate which banks are nonvolatile.

Edit 2: By the way, which games support 128KB of RAM. My emulator is currently only allocating 64KB max.

Edit 3: There are indeed 11 MMC5 with nonvolatile RAM, plus a Rockman 4 hack I dug up:

Aoki Ookami to Shiroki Mejika - Genchou Hishi
Bandit Kings of Ancient China
Gemfire
Ishin no Arashi
Just Breed
L'Empereur
Rockman 4 - Minus Infinity (Hack)
Metal Slader Glory
Nobunaga no Yabou - Bushou Fuuun Roku
Nobunaga's Ambition 2
Romance of The Three Kingdoms II
Uncharted Waters

Here are the ones without a battery (most are homebrews):

2-Frame Flicker Palette Demo (br-gr) by strfr (2007) (PD)
AIR Demo for MMC5 by KZ-S (20051123) (PD)
AIR Opening for MMC5 by KZ-S (20060225) (PD)
BAPSACRSTRKCGTF (Demo Phase 1) (AKA B00daw's Folly) (PD)
Cat Pic Digitized (PD)
Colortest (PD)
Castlevania III - Dracula's Curse
Demo3 for Mapper 5 (PD)
Firefly Demo by Loopy (PD)
Laser Invasion
Life Force
Multi-Layered Scrolling Demo Choppy by strfr (2007) (PD)
Shin 4 Nin Uchi Mahjong - Yakuman Tengoku
Teenage Mutant Ninja Turtles DEMO (PD)
Uchuu Keibitai SDF

Castlevania III really needed one :(

Edit 4: For my emulator, when nonvolatile RAM is available per the file header (or cart DB), I'll make it save the standard battery backed memory region ($6000-$7FFF) and any extra PRG RAM chip data. Currently, it's just saving the former of those 2. If there is a better way, please let me know.


Top
 Profile  
 
PostPosted: Sat Jan 05, 2019 2:41 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8372
Location: Seattle
zeroone wrote:
I only see it reading and writing to banks 3 and 4 during gameplay and during save/load city. So, I'm leaning on bank 4. Is there a way to confirm this?
It's definitely "W-RAM-0" that's battery backed and "W-RAM-1" that's not. Which I think means that it's banks 0-3 that are battery-backed and banks 4-7 that aren't.

On the other hand, the only way it would be problematic to emulate all RAM as battery-backed is if the game uses the contents of that RAM as a RNG seed. We do know that a few games do rely on cart RAM acting this way, such as Impossible Mission 2. But I don't know if any of the SOROM and ETROM games do.

zeroone wrote:
Edit 2: By the way, which games support 128KB of RAM. My emulator is currently only allocating 64KB max.
None. No commercial games ever used more than 32 KiB of RAM.

As the wiki says, we didn't even know that more than 64K were supported until last month when Ben Boldt discovered it.

Quote:
I'll make it save the standard battery backed memory region ($6000-$7FFF) and any extra PRG RAM chip data.
Er ... what do you mean by this? I'm not clear what distinction you're making here.


Top
 Profile  
 
PostPosted: Sat Jan 05, 2019 4:45 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 911
Location: New York, NY
lidnariq wrote:
Er ... what do you mean by this? I'm not clear what distinction you're making here.


For MMC5, I'm going to store the full 32 KiB of PRG RAM in addition to anything present in the 8 KiB of data in the $6000--$7FFF range, even if there is overlap. In other words, in general, I don't know which extra PRG RAM banks are battery backed. So, I'll persist it all.


Top
 Profile  
 
PostPosted: Sat Jan 05, 2019 5:06 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8372
Location: Seattle
zeroone wrote:
For MMC5, I'm going to store the full 32 KiB of PRG RAM in addition to anything present in the 8 KiB of data in the $6000--$7FFF range, even if there is overlap.
But that explicitly breaks PRG RAM banking? There isn't a fixed bank of RAM at $6000 on MMC5 ever; every cart can elect to map a different bank (ETROM, EWROM) or open bus (EKROM, ELROM) there instead.

You can't even restore from that condition correctly. Unless you're implementing something godawful where you fake banking using memcpy, in which case please don't. It's not how the hardware works, and one can trivially write something that will tank performance by making it memcpy 8k every couple 6502 instructions.

You also can't assume that the data that's at $6000 at the exact moment of emulation halt is the data that needs to be saved...

Furthermore, no commercial game ever needs anything but the bottom 32K saved.

Quote:
In other words, in general, I don't know which extra PRG RAM banks are battery backed. So, I'll persist it all.
But that's not the same thing. Saying you'll just always save banks 0-3 should be safe: no commercial game needs more. Saying you'll always save banks 0-7 is a defensible way to support unknown homebrew, although ideally it'd have NES2.0 headers to say how much you should save anyway.


Top
 Profile  
 
PostPosted: Sun Jan 06, 2019 9:00 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 911
Location: New York, NY
I agree entirely. Without going into implementation details, what I'm doing is effectively the latter; i.e. along the lines of "save banks 0-7 is a defensible way to support unknown homebrew".


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 11 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