It is currently Fri Mar 22, 2019 5:57 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 42 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Sat Mar 09, 2019 10:23 pm 
Offline
User avatar

Joined: Fri May 21, 2010 4:10 pm
Posts: 306
Just for some clarification here, Nestopia actually plays this rom OK and fine with no issue.

After speaking with Lidnariq, the rom starts up as EKROM (nestopia's default) when it should be ETROM, after setting the rom header to ETROM, Nestopia plays this just fine with no Map issues. Thank you Lidnariq! :beer: I overlooked this little issue when testing out the rom. :(

I had to use a hex editor to hex the rom to get it work in Nestopia. So i guess, the database needs an entry for this game to work correctly without having to tinker with the rom in a hex editor or rom tool?


Top
 Profile  
 
PostPosted: Sat Mar 09, 2019 10:38 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3958
Location: A world gone mad
Nice find. Yes, Nestopia will need an override in its internal NstDatabase.xml file for this game. Once fixed, the next version of NestopiaUE would have it working for everyone. But you can tweak your own local .xml file and have NestopiaUE refer to it.

Go to Options -> Database. "Internal" refers to the NstDatabase.xml that comes with NestopiaUE, "External" refers to an external (additional) .xml file of the same sort/syntax as the internal one but with your own tweaks. I don't know how user-friendly the XML parser is, so if you mess it up or bust it I dunno what will happen.


Top
 Profile  
 
PostPosted: Sun Mar 10, 2019 12:16 pm 
Offline
User avatar

Joined: Fri May 21, 2010 4:10 pm
Posts: 306
After fixing the header data in the rom, Everything looks OK, but now when you go to practice mode, the map has stuff all over the place. Everything else looks good.

So, for the most part that did fix most of the issues except for practice mode. Something is still just a tad off.


Top
 Profile  
 
PostPosted: Sun Mar 10, 2019 6:54 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3958
Location: A world gone mad
As per PM: I suspect the issue may relate to what the default PRG-RAM bank chosen is on power-on. It may need to be the upper half (or the lower half). If that's not it, it may be an actual MMC5 emulation quirk; maybe relates to what zeroone/etc. were talking about earlier?


Top
 Profile  
 
PostPosted: Sun Mar 10, 2019 11:23 pm 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 880
Scenarios maps are also broken.

If I recall correctly, preset maps are read from CHR-ROM via $2007, and if an emulator keeps the emulation of EXRAM-based CHR bankswitching active even after rendering has been disabled via $2001, then they will be read from the wrong CHR-ROM bank.


Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 2:24 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3958
Location: A world gone mad
I've asked Spitfire_NES to stop contacting me in PM about this. I know for a fact there are at least 3 separate PMs happening and suspect are all duplicating efforts etc. and that's a waste of everyone's time. Likewise, having these discussions *publicly* is universally good considering rdanbrook is watching the thread, and future emulator authors may need to know this. PMs are not the way to go about this.

Let me establish some data/facts here. This game has several problems on stock NestopiaUE 1.49 (stock means no code changes or .xml tweaks). These are the ones I noticed:

1) Practise Mode: starting map is filled with a lot of wrong tiles/icons/data. If fast-forwarding a bit, the game will report something like "Congrats! Your population has grown to <some number that is random>". The random number is indeed exactly that -- if I delete the .sav and try it all again, the population will be completely different every time.

2) Start New City: map generation results in no visual changes (i.e. whole "preview" map consists of purple/blue tiles). Upon starting the game anyway, the graphics in the actual playfield map are mostly garbled.

3) The game uses an original NES header that simply reports it's MMC5. The auto-chosen board type (EKROM) is incorrect for this game; it needs to be ETROM. lidnariq discovered this. Nestopia's source code does have ETROM support, though if it's correctly implemented for this game is a different question.

4) PRG-RAM amount is incorrect. It's reported as 8KBytes when the game actually has 2x8KB SRAM chips on it (source image: Images\Photos\Prototype Cartridge Photos\IMG_1629.jpg -- I've attached that photo, rotated for convenience). These are Sony CXK5864PN-15LL chips, which were used on other games too, so their size is indeed correct. There is a battery on the cart, however I cannot determine if one or both of the SRAM chips are battery-backed. More on that in a moment.

Use of NES 2.0 header would alleviate (3) and (4), however NestopiaUE does not support NES 2.0 so it's a moot point for the purpose of getting the game working. I also don't think rdanbrook is going to implement that any time soon, so fixing the emulator code and applying necessary XML tweaks is probably a better choice.

I started by making my own External .xml file, which is used in combination with the Internal one. I started with this:

Code:
<?xml version="1.0" encoding="UTF-8"?>
<database version="1.0" conformance="loose">
    <game>
        <cartridge system="NES-NTSC" dump="ok" crc="FDC7C50B" sha1="5E8F67BEFB2B1BCBD0384E3144ACB2766FC3E443">
            <board type="NES-ETROM" mapper="5">
                <prg size="128k" />
                <chr size="128k" />
            </board>
        </cartridge>
    </game>
</database>

With the above configuration, we get these results:

1) No change in behaviour.

2) Fixed; the generated map preview now looks OK, and the in-game graphics/map now look OK too.

3) Fixed; NestopiaUE now thinks it's ETROM.

4) Possibly fixed but unsure; NestopiaUE reports "W-RAM: 16KB". However, NestopiaUE code-wise has two different types of handling for larger-than-8KB PRG-RAM: you can have a single 16KB PRG-RAM, but you can also have something like 2x8KB PRG-RAM, which also gets reported as "16KB", which makes testing confusing. "Battery: No" is still present.

In attempt to solve (1) and (4), thinking maybe they're related, I add the following 2 lines to the <board> section. This is based on similar entries in the XML for other non-MMC5 games:

Code:
                <wram size="8k" />
                <wram size="8k" battery="1" />

Results:

1) No change in behaviour.

4) "Battery: Yes" now appears and a single 8KB .sav file is generated on ROM close or emulator exit... however, whether or not this is the correct XML config to use I'm still not sure of. Likewise, as said, I still don't know if this game battery-backs both SRAM chips or not, so I can't tell if the emulator should be writing a 16KB .sav or not. More on that in a moment (yes, again!).

I then change the 2 above lines to this:

Code:
                <wram size="16k" battery="1" />

But the situation remains the same. Likewise, NestopiaUE still only results in an 8KB .sav file. I remember dealing with this with another unrelated game (a Koei title, I think), but I digress. I also tried using two of the above lines (i.e. two 8KB with battery="1") but the result was still an 8KB .sav. I reverted back to the 2-wram-lines method since that seems to be more true to what the physical PCB contains.

I then decide to switch gears a bit asking: "what does Mesen do with this game?" The behaviour there (using DevWin-0.9.7.92) differs quite severely from NestopiaUE. One piece of data is that Mesen reports "[DB] Game not found in database", so there are no internal DB overrides for this title in Mesen, which means "it's working" better out-of-the-box. But here are the details:

1) Practise Mode works fine. However, different in behaviour here: there is no "Congrats! Your population has grown to <some random number>" unlike Nestopia; instead, consistently the game reports "Congratulations Mr. Mayor! A new town has been created." I suspect NestopiaUE is doing something weird, possibly PRG-RAM-related. Possibly this relates to the earlier code fixes/tweaks discussed by zeroone (and rainwarrior too, I think?).

2) Start New City works fine too.

3) Can't tell what board type Mesen is using (nothing in Log Window), however I suspect ETROM given that (2) is OK.

4) PRG-RAM size is also not reported in Log Window. It does say that the game is battery-backed. However, upon exiting the game, the resulting .sav file is 64KBytes.

Because of (4), I decided to look around in Mesen's debugger during gameplay to see if I might be able to determine what's going on, in addition to looking at the resulting .sav in a hex editor.

First thing I noticed is that the game maps $6000-7FFF to PRG-RAM bank $04, while $8000-9FFF gets swapped between ROM bank $0C and PRG-RAM bank $00 periodically. The PRG-RAM regions are labelled "R", whatever that means. $5C00-$5FFF is labelled "W". (Boy I sure wish Mesen's Event Viewer List View tab had a filtering capability similar to the PPU View tab! I'd love to see just mapper reads/writes, for example).

Examining the 64KB .sav file shows that there is used areas ranging from file offsets $02C0 to $0830 (it just sort of varies), as well as from $8000 to $9690. I suspect what Mesen is doing, in contrast, is simply saving all possible PRG-RAM banks (8x8KB) to a single 64KB file as an easy way to deal with the situation, given how annoying >8KB battery-backed PRG-RAM can be to deal with (see above).

Back to NestopiaUE: because of this discovery, I tried the following for PRG-RAM in the XML, just as a kind of crappy "let's see if this works but I doubt it" approach:

Code:
                <wram size="64k" battery="1" />

But the results were the same as above -- Image Info still reported "W-RAM: 16KB" and still an 8KB .sav. Same if I did 8 repeated 8KB lines, blah blah blah.

So that's what I know as of this writing. I suspect there are MMC5 emulation bits that are not quite correct, compounded with other complications.


Attachments:
IMG_1629.JPG
IMG_1629.JPG [ 2.75 MiB | Viewed 323 times ]
Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 4:46 am 
Offline
User avatar

Joined: Fri May 21, 2010 4:10 pm
Posts: 306
Thanks for posting that up Koitsu and taking the time to research some of this! Yes, Lidnariq notified me that indeed this game is being loaded up as EKROM instead of ETROM as it should be. From there, that is pretty much it, I hexed the rom from there to arrive at the same results you have. I had planned on making an xml fix for this yesterday but didn't get around to doing it.

1. Rdanbrook did add initial support for Nes 2.0 here: https://github.com/0ldsk00l/nestopia/co ... 695c38c356

2. There were no other tests with Lidnariq to report, it was only to the extent of Nestopia is loading the game incorrectly and then he passed along the info so I could hex the rom to at least get it to a point to see what he was seeing. If not for me reaching out I would have never thought to check for that issue as I thought the game was being loaded correctly. Imagine my surprise when he responded saying it worked for him. :lol:

3. Any information I do come across I almost always do pass it off to Rdanbrook. Recently I had a discussion with Rainwarrior about SimCity on nestopia and immediately passed along the information about Nestopia MMC5 incorrectly not ignoring the upper bits of registers 5102 and 5013 to Rdanbrook back on March 3, which leads me to the note below.

https://github.com/0ldsk00l/nestopia/issues/311

Note* Even with this code above active and tested on sim city, it has no effect on the map being full of tiles/buildings when starting practice mode as I tested this again recently and yesterday after loading the rom with the correct info.

4.I see now there is another issue as I'll have to go back and re-test as NewRisingSun is reporting that scenario maps are also broken. Even though he stated this a couple posts above. Weird as I thought I tested those yesterday. I'll go ahead and re-add this here:

"If I recall correctly, preset maps are read from CHR-ROM via $2007, and if an emulator keeps the emulation of EXRAM-based CHR bankswitching active even after rendering has been disabled via $2001, then they will be read from the wrong CHR-ROM bank"

Does the above quote sound similar to what GreyRogue did? He got his maps working In Mister by disabling the external attribute mode (palette and the address override) when not in frame. <---(I am not quite sure how to do that).

That's basically the extent of everything I know. Most likely as you said, it might be something a little off with ETROM emulation OR something off in the MMC5 emulation itself. I am not quite sure how to do exactly what GreyRogue did. As I find more info I will post it here until it is solved. There is only one other issue with MMC5 on nestopia I am aware of and I doubt it has anything to do with this.

EDIT** Yep, NewRisingSun is correct, the scenario maps are also busted, though I suspect there is relation to this and the practice maps being full of tiles too.


Last edited by *Spitfire_NES* on Mon Mar 11, 2019 6:07 am, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 5:19 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 880
Not using EXRAM tiles/attributes when not in-frame is a question of MMC5 emulation itself. It is not something that you can affect with a header or database change. Yes, the actual MMC5 keeps track of whether the PPU is currently rendering, and does not use EXRAM extended tiles/attributes when rendering is disabled via $2001 or during vertical blanking, so that behavior must be replicated by emulation.

Edit: I can cause and not cause the garbled Practice/Scenario issue in NintendulatorNRS by disabling and enabling the querying of the in-frame status in the EXRAM emulation, although the garbage tiles are different ones than in Nestopia.


Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 9:11 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 8177
Location: Seattle
NES2.0 support, but no submappers, has been in Nestopia since Freij's releases v1.35.


Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 9:50 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 880
koitsu wrote:
But the results were the same as above -- Image Info still reported "W-RAM: 16KB" and still an 8KB .sav. Same if I did 8 repeated 8KB lines, blah blah blah.
ETROM battery-backs only the first of the two 8 KiB RAM chips. The "first" chip is the chip that is being selected when the chip-selecting address bit is clear. The correct NES 2.0 header therefore has 8 KiB of PRG-RAM and a further 8 KiB of PRG-NVRAM, yielding in a .SAV file correctly being 8 KiB in size.


Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 9:52 am 
Offline
User avatar

Joined: Fri May 21, 2010 4:10 pm
Posts: 306
NewRisingSun wrote:
Not using EXRAM tiles/attributes when not in-frame is a question of MMC5 emulation itself. It is not something that you can affect with a header or database change. Yes, the actual MMC5 keeps track of whether the PPU is currently rendering, and does not use EXRAM extended tiles/attributes when rendering is disabled via $2001 or during vertical blanking, so that behavior must be replicated by emulation.

Edit: I can cause and not cause the garbled Practice/Scenario issue in NintendulatorNRS by disabling and enabling the querying of the in-frame status in the EXRAM emulation, although the garbage tiles are different ones than in Nestopia.


Thanks so much for doing this NewRisingSun and good catch! Sounds like this could possibly be the culprit here!


Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 10:40 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 21209
Location: NE Indiana, USA (NTSC)
NewRisingSun wrote:
ETROM battery-backs only the first of the two 8 KiB RAM chips. The "first" chip is the chip that is being selected when the chip-selecting address bit is clear

I was under the impression that SOROM battery-backed only the second. Is my understanding correct that SOROM and ETROM differ on the meaning of this bit? If so, that's something that should be clarified in the wiki.


Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 10:44 am 
Offline

Joined: Thu May 19, 2005 11:30 am
Posts: 880
Correct: the MMC1-based two-WRAM-chip SOROM and SZROM boards battery-back the second chip and not the first, while the MMC5-based two-WRAM-chip ETROM board battery-backs the first chip and not the second.


Top
 Profile  
 
PostPosted: Mon Mar 11, 2019 11:32 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3958
Location: A world gone mad
lidnariq wrote:
NES2.0 support, but no submappers, has been in Nestopia since Freij's releases v1.35.

Ah ha, it might be the "no submappers" part that has made me think there's no NES 2.0 support in it. Thanks for clarifying/educating me.


Top
 Profile  
 
PostPosted: Thu Mar 14, 2019 10:47 am 
Offline
User avatar

Joined: Fri May 21, 2010 4:10 pm
Posts: 306
OK, I am attempting to sit down and look at this myself here. I figure this maybe won't be hard to pinpoint or at last disable the code that query's the in-frame status. I did some digging through the nestopia source code here:

https://github.com/0ldsk00l/nestopia/bl ... rdMmc5.cpp

I attempted to look through and found this:

Code:
NES_PEEK(Mmc5,5204)
         {
            Update();

            const uint status = irq.state & (Irq::FRAME|Irq::HIT);
            irq.state &= (Irq::FRAME|Irq::ENABLED);

            cpu.ClearIRQ();

            return status;
         }


But attempting to disable this throws a ton of compiler errors. Is this not the correct place to be looking? I'm no code wiz but I'm not sure where else it could be in this confusing mess of mmc5 barbwire, so please excuse the noobness. :mrgreen:

Now I know this is for register 5204, but nothing else immediately stands out that points to a "query". Or is NST_VERIFY more viable here?


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

All times are UTC - 7 hours


Who is online

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