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.dougeff wrote:Someone told me that the game was only 50% complete.
Are we sure that the game is even playable?
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)
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.Greg2600 wrote:Argh, MMC5! Won't work on a flash cart.
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: If the source for an existing MMC5 flash cart mapper is available, it shouldn't be too hard to fix.
- Krikzz MMC5 mapper source
- (195.88 KiB) Downloaded 139 times
lidnariq wrote:Out of curiosity, what?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.
Code: Select all
// unpack ppu flags wire ppu_in_frame = ppuflags; wire ppu_sprite16 = ppuflags; wire [8:0] ppu_cycle = ppuflags[10:2]; wire [8:0] ppu_scanline = ppuflags[19:11];
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.
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.getafixx wrote:Krikzz released his MMC5 mapper source a while back for the EverDrive N8 cart.GreyRogue wrote: If the source for an existing MMC5 flash cart mapper is available, it shouldn't be too hard to fix.
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.