Someone's found a prototype cartridge of SimCity!!
https://www.youtube.com/watch?v=V7-M_LcqJscBeen hoping this would appear for a long time now. I'm excited to finally hear the music from it especially.
Looks better than I have expected(I think all we got before was a screenshot with the menu icons on the left), especially with the not-so-tiny navigation map while scrolling through the field, making it a "16-bit like" game. I bet that eats most of the 64-sprite bandwidth already (maybe they use 8x16 sprites).
I think apart from favouring the SFC version over it, another possible reason for it not being released is manufacture cost. It's (almost) certain that the cart contains extra RAM (probably with battery backed-up portion for saving too) as the internal 2kb work RAM couldn't be enough for its random destructible constructible terrace. It's just not a good commercial deal to release something like this near the end of the console's life.
Yeah, it looks suprisingly good! They did a really good job on the interface.
The minimap/lookaround solution seems unique/visionary, even if it is derived from the problem of porting the game to a console with a feature set not designed with this type of game in mind.
It would have fared better if flashROM had been a commercially viable thing for the NES. Apparently it was
invented by a toshiba employee in 1980 and made available in 1984, but must've cost a lot.
I've been waiting for this too! I couldn't hear the music in the video though, because of the loud commentaries.
Now if they just got it dumped.
MMC5, two 32 KiB SRAMs ... small wonder it didn't make it to production.
I feel like there should be some way to search the FFTs of the audio for things that match the spectrum of a square or triangle wave, to reject all the useless commentary, but I have no idea how to implement the search portion...
Well, despite the commentary, the music seemed sonorous and triangle-wave-heavy, almost as if the square wave channels had been subdued or muted.
Wow, it's been a phenomenal year for retro-gaming.
-Nintendo Playstation prototype #1 working.
-Starfox 2 retail version release very soon (but not holding my breath for major differences from beta version).
-Sega Saturn console booting from a USB flash drive by tapping into video decoder card slot.
-64DD North American retail version found at a garage sale (one of a kind).
-And now this NES SimCity game I've long since given up on ever seeing.
stuff I still hope yet to be found?
Dragonfly (SNES)
KI2 (SNES)
...Any squaresoft SNES CD prototype like Secret of Mana or Chrono Trigger???
lidnariq wrote:
I feel like there should be some way to search the FFTs of the audio for things that match the spectrum of a square or triangle wave, to reject all the useless commentary, but I have no idea how to implement the search portion...
There's some expensive software called
Melodyne that works on this kind of principle to separate pitched sounds.
I did some experiments with similar a few years ago. I got some very rough separation of tones and noise, and it could try to identify chords etc. but I think there's a ton of refinement work on how to detect/select/separate tones that needs to be done before it's past the basic proof of concept stage. Even Melodyne isn't really as good as the cherry-picked examples in its ads makes it look, but I was quite impressed with how far beyond it was from the basic stuff I was doing.
Dunno if anyone's tried to make the GIMP equivalent of Melodyne yet, though it's on my list of projects that may someday become interesting enough to me to take priority again.
I can see MMC5 extended attributes here. This could have been the game to finally show off the amazing features of the MMC5, rather than those Koei Games or Castlevania 3.
I'm hoping someone dumps this (or repros it). I'd love to see it.
It doesn't look nearly as complete as I was hoping. Is this just an early prototype?
For the impatient, there is an open-source city-building game for the GBC:
Get this "µCity 1.0" for free here:
https://github.com/AntonioND/ucityOr watch some game play:
https://www.youtube.com/watch?v=2rir-TVx020
lidnariq wrote:
MMC5, two 32 KiB SRAMs ... small wonder it didn't make it to production.
I feel like there should be some way to search the FFTs of the audio for things that match the spectrum of a square or triangle wave, to reject all the useless commentary, but I have no idea how to implement the search portion...
do they say in the video it has 2x 32K ram? or where did you get that from? I don't have audio at work.
FrankWDoom wrote:
do they say in the video it has 2x 32K ram? or where did you get that from? I don't have audio at work.
MMC5 is presumed from the 8x8 attributes.
Further presuming that 8k WRAM is not enough space to save the city state, there's no 16k chip (but you can do 2x8k), so the next size up is 32k. The MMC5 supports 2x32k (64k) at maximum.
So I think lidnariq is either presuming this maximum 64k of WRAM (2x32k), or presuming 32k WRAM and 32k CHR-RAM (could do pattern RAM banking). I'm not sure which.
SNES SimCity had 256k RAM inside it, for comparison, which could save two cities, so that might put an assumption for 64k WRAM being necessary into perspective.Edit: never mind, it was 256 kilo
bit, so 32k.
rainwarrior wrote:
So I think lidnariq is either presuming this maximum 64k of WRAM (2x32k), or presuming 32k WRAM and 32k CHR-RAM (could do pattern RAM banking).
The pictures of the PCB (in the cut up gold shelled prototype) show a NES-ETROM board with two RAMs, both socketed. Since ETROM comes by default with 2x8K RAM, the only reason to socket them would be if they needed at least one larger RAM.
(The picture also shows a UVEPROM for CHR-ROM)
—
The original DOS SimCity saves its cities in a consistently and exactly 27248 bytes, ending with the map itself stored as a 100x120 array of uint16s. Obviously they could have shrunk the world for the NES release, but ...
I guess it they could possibly have landed on "just" needing 40K... but without having actually looked at the Micropolis source code, I suspect they might double-buffer the world state. And the picture shows an extremely similar SRAM in both sockets.
so with the mmc5 using 2 ram chips, could you simulate that setup with one ram chip? using the ram 0/1 enable lines to toggle the high address line? or do they have to be 2 physical chips for some reason?
edit: maybe there isn't a suitable single ram chip that big? what would be the part # for that?
Yeah, you could use /RAM1CE as A15, and AND(/RAM1CE,/RAM2CE) as /BiggerRAMCE, if you could get your hands on a ≥64 KiB SRAM.
But NES-ETROM is already nicely set up for this upgrade (SL15/CL15), and I'm pretty certain it'd be easier to piggy-back an extra RAM onto NES-EWROM.
ideally yeah. but if I ever have the option to make a cart out of this, I'd rather not sacrifice a NES ETROM cart for reasons of cost and ruining something I'd otherwise collect. so it's down to modifying a lesser board, or famicom carts.
rainwarrior wrote:
SNES SimCity had 256k RAM inside it, for comparison, which could save two cities, so that might put an assumption for 64k WRAM being necessary into perspective.
SimCity (Super NES) battery RAM is 256 kbit, same as SXROM/EWROM. (Source:
SnesCartDB)
lidnariq wrote:
The pictures of the PCB (in the cut up gold shelled prototype) show a NES-ETROM board with two RAMs, both socketed.
I'm guessing that's an
ETEPROM board, rather than an ETROM that they socketed. So, not necessarily bigger than 2x8k. That photo came from an old eBay auction for a Laser Invasion proto, btw.
tepples wrote:
SimCity (Super NES) battery RAM is 256 kbit
Thanks for the correction (and the helpful link to an SNES cartridge database).
The SNES has 128KB of onboard RAM, so the entire cartridge RAM can be dedicated to save data. On the NES it's most likely that one of the two cartridge RAMs is work RAM and the other is save data, just like all the Koei games.
FrankWDoom wrote:
ideally yeah. but if I ever have the option to make a cart out of this, I'd rather not sacrifice a NES ETROM cart for reasons of cost and ruining something I'd otherwise collect. so it's down to modifying a lesser board, or famicom carts.
Out of the MMC5 PCBs that support any WRAM, ETROM is the most common. EKROM and EWROM are only used by one US game each (Gemfire and ROT3KII respectively); ETROM is used by four (Bandit Kings of Ancient China, L'Empereur, Nobunaga's Ambition II and Uncharted Waters)
On ELROM, you could piggy-back a 32-pin 128Ki x 8 SRAM on top of (or underneath) the existing PRG-ROM, without too many random bonus wires... but it is an awful lot of fiddly rework, including a good deal of SMT work to get to the pins on the MMC5 that aren't broken out.
maseter wrote:
there is an open-source city-building game for the GBC:
[...]
Get this "µCity 1.0" for free here:
https://github.com/AntonioND/ucityIt's telling that this is GBC exclusive for the same reason that
SimCity would have been expensive to replicate: it needs a comparative ton of work RAM.
So do we know if anyone has tried to get in touch with the person to see about dumping the game? Other than wanting to try game myself like most everybody else here, I'd REALLY hate to see it eventually lost forever if the eproms finally give out and it was never dumped.
cr4zymanz0r wrote:
So do we know if anyone has tried to get in touch with the person to see about dumping the game? Other than wanting to try game myself like most everybody else here, I'd REALLY hate to see it eventually lost forever if the eproms finally give out and it was never dumped.
Bump.
It's been dumped and preserved. I believe the data is currently in the backlog of Frank Cifaldi who will eventually release it?
https://www.youtube.com/watch?v=oqqz_XTLajQ
Let's hope that this game stores its music data in 1 fixed bank. : P
Nintendo drivers aren't hard to rip, but it takes a while to arrange them properly.
rainwarrior wrote:
It's been dumped and preserved. I believe the data is currently in the backlog of Frank Cifaldi who will eventually release it?
FYI, Frank Cifaldi released the Simcity NES prototype earlier today.
.. It's just running on ordinary ET(EP)ROM, with just 16 K of memory??
the photo i've seen shows an eteprom board with no obvious alterations, so i'm assuming that's what's going on. away from home right now but i've got some famicom donors stashed away to try this on a cart.
If on ETROM, the city must be smaller than the standard 120x100 cell city.
It turns out it's 76x76.
A few other changes have been made to compensate: PD/FD/RCI zones are 2x2 (not 3x3); power plants, stadia, and seaports are 3x3 (not 4x4); airports are 4x4 (not 6x6)
Is anyone selling these? (just curious)
We'll know
SimCity is getting bootlegged if eBay prices for
same-board Koei games (
Bandit Kings of Ancient China,
L'Empereur,
Nobunaga's Ambition II, and
Uncharted Waters) shoot up.
Probably not a huge risk there, as the NES version of the PCBs are all on games that are prohibitively expensive already.
Argh, MMC5! Won't work on a flash cart.
Might. It's not using much of the MMC5 beyond 8x8 attributes w/ 16k tile mode.
I wouldn't be surprised if Loopy's MMC5 implementation is adequate.
It has screwed up graphics on Everdrive. It says it's loading on Powerpak, I have the loopy mappers, but then is just a black screen. So it does not appear to work on flash carts currently
Yeah, this is probably the only game that stresses the MMC5?
@lupin3rd
To make it from famicom boards would be easier since there must be a pile of Koei games in every bookoff shop
(saw one 2 days ago, complete box for a few hundred yen).
But then MMC5 boards are longer than other Famicom cart boards. How would one roll a JOINT to fit it and the board in the NES Game Pak shell?
there are low profile adapters available that will fit a tall famicom board in a nes shell. may require relocating some components but it can be done.
Why am I giving ideas for making repro
Jedi move: there is no such thing as pile of Koei famicom games, no such thing.
Banshaku wrote:
Why am I giving ideas for making repro
Jedi move: there is no such thing as pile of Koei famicom games, no such thing.
The problem there is that NES owners would need both the gigantic ETROM PCB, as well as a 72-pin adapter, all jammed into an already crammed cart.
Disclaimer: I ordered my Famicom copy of L'Empereur yesterday.
I have one devcart somewhere but I never used it (I think I did prepare the sockets for the flash eeprom). I will have to check someday if it's compatible with it.
Someone told me that the game was only 50% complete.
Are we sure that the game is even fully playable?
Are there stretches of mostly 6502 code without the new 65816-specific instructions (STZ, INC A, etc.) in the Super NES version of SimCity, Tetris & Dr. Mario, Yoshi's Cookie, or Wario's Woods? I ask because it might point at practices of sharing code between the NES and Super NES versions of a game.
dougeff wrote:
Someone told me that the game was only 50% complete.
Are we sure that the game is even playable?
My understanding is that there was a bug that prevented the game from being completed. I also understood this to be an incomplete prototype that had lots of unused graphics (unimplemented, I believe) for the build. The news that is spreading says that someone had disassembled the prototype and commented the code pretty extensively, and I believe fixed a couple of bugs along the way. Not sure where that leaves the playability though.
Playable, yes: I can place zones and have them develop, traffic is simulated, &c.
Complete? Definitely not. There's an education overlay but no education zones. Residential zones seem to only have the "low density" form. There's plenty of other missing things. Several scenarios just don't work (Bern)
The archive.org download includes reverse engineering notes from (pretty certain) Санчез, which includes a very large "unfinished" section. (Certainly the actual disassembly is marked as his)
Looking at the video, I don't understand how the metatiles and palettes could have worked: Most types of construction are 16x16 pixel squares, but they can be aligned to any 8-pixel boundary. You'd think that would lead to Marble-Madness-style attribute leaking alongside adjacent tiles, but I don't see any evidence of that. Anyone know (or want to venture a guess) as to how they did it?
wouldn't be surprised if it used a board with 8x8 attributes.
edit - yup, it's on MMC5
Greg2600 wrote:
Argh, MMC5! Won't work on a flash cart.
I've got it working in MiSTer (FPGA) in my fork (MMC5 mapper originally written by Ludvig Strigeus, I believe, with a few fixes from me). It uses a few flags it gets directly from the NES core, which will need to be translated for a flash cart, but it should be doable.
If the source for an existing MMC5 flash cart mapper is available, it shouldn't be too hard to fix.
GreyRogue wrote:
If the source for an existing MMC5 flash cart mapper is available, it shouldn't be too hard to fix.
Krikzz released his MMC5 mapper source a while back for the EverDrive N8 cart.
GreyRogue wrote:
It uses a few flags it gets directly from the NES core, which will need to be translated for a flash cart, but it should be doable.
Out of curiosity, what?
lidnariq wrote:
GreyRogue wrote:
It uses a few flags it gets directly from the NES core, which will need to be translated for a flash cart, but it should be doable.
Out of curiosity, what?
Code:
// unpack ppu flags
wire ppu_in_frame = ppuflags[0];
wire ppu_sprite16 = ppuflags[1];
wire [8:0] ppu_cycle = ppuflags[10:2];
wire [8:0] ppu_scanline = ppuflags[19:11];
sprite16 can be sniffed from writes. The others are doable, but a little harder.
Some of the things it does:
It uses external attributes and external nametables, but it uses the nametables interface to get data into and out of the ExRAM whether or not the data is actually nametable data. So for the title screen, it sets it for nametable mode, then uses the PPUADDRESS/DATA (2006/7) to write data to the ExRAM. It then reads back data from the 2006/7 area and writes it to different addresses for sections that are the same. All of this data for the title screen is actually external attribute data, not nametables, though, so it switches to that mode before it starts rendering it. So all of the ExRAM stuff needs to to work correctly for the graphics to show correctly. Why it didn't just use the 5C00-5FFF range instead...I don't know.
getafixx wrote:
GreyRogue wrote:
If the source for an existing MMC5 flash cart mapper is available, it shouldn't be too hard to fix.
Krikzz released his MMC5 mapper source a while back for the EverDrive N8 cart.
Unless I'm just not seeing it, I don't see where the Extended RAM attributes are handled. The game uses these. Graphics will be corrupted without them.
I just tried it [V20 rc6] and it seems very playable. The first few title screens are garbled but the game itself runs fine. How "finished" is it? I'm not sure, but it definitely seems to function as the original PC game did.
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.
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.
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.
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?
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_MiSTerhttps://github.com/MiSTer-devel/Main_MiSTer/wikiMy fork has a few more fixes I haven't pushed to the main repository yet, and SimCity works in it.
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.
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.
GreyRogue wrote:
Note that it's FPGA. The NES core requires the SDRAM board in addition to the DE10-Nano.
So much for testing then.
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.
By the way, is MMC5 WRAM nonvolatile? I noticed that you can save your city. Where does it go?
It's the standard ETROM behavior. I forget whether that means bank 4 or bank 0 is the one that's nonvolatile, though.
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.
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.
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.
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.
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".