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.