Problem converting 256 KB MMC-1 to 512 KB MMC-1

I want to convert my current game from a MMC-1 with 256 KB to MMC-1 with 512 KB.
I did all the changes that I think are needed, but the game doesn't start anymore.

This is what I did:

I changed the fifth value in the NES header from 16 to 32:

I added new memory and segment entries in the config file.

Those are the corresponding original values:


Here, I put bank 15-30 between 14 and fix.

Same with the code itself.

Original versions:


I added bank 15-30 between bank 14 and bank fix.

By the way, RESET_START is a macro that contains this code:

All in all, the version with 16 banks works fine. But with 32 banks, it doesn't even start.

So, what else do I need to add, so that the code works?

The MMC1 mapper was only designed to do 256k normally. The 5th bit of the "PRG" register actually controls PRG-RAM enable, not PRG banking. The high bit of 512k PRG select was achieved by reusing a line from the CHR banking registers on some boards. It's a terribly overloaded situation, unfortunately. You might find emulators that won't even use the high bit like that without a CRC match.

Well, there are two non-obscure, American MMC-1 cartridges with 512 KB PRG ROM: "Dragon Warrior III" and "IV".

So it looks like MMC-1 512 KB mappers were not only used by some unknown company in games that nobody remembers, but this mapper type actually exists inside the list of the popular, famous titles.

So, should I stick with MMC-1 and check how to change the code accordingly?
Or should I switch to MMC-3?

Yes, but it's still a hack. They repurposed a CHR address line to select between 2 256KB of a 512KB PRG chip, so the result is more like a multicart with 2 256KB MMC1 programs that can switch to each other.

If you stick to the MMC1, you have to design your program around that model. One solution is to use one of the 256KB halves mostly for graphics and audio, so you don't need to jump back and forth during game logic.


I'm not a big fan of the MMC1 anyway, so I think this would be a huge upgrade. In addition to the much improved memory mapping capabilities, you'll get a decent scanline counter that'll open a world of possibilities for raster effects.

O.k., I'll switch to MMC-3 then.

Since my game is a top-down action adventure like "Zelda", raster effects aren't really necessary, but I can finally abolish sprite 0 for the nametable switch when a dialog box is open.

Also, my graphics artist can then do animated backgrounds.

I don't see what you mean by "overloaded" in this case. In all MMC1 boards with 4 Mbit PRG ROM, A18 on the program is connected to the mapper's CHR A16 output.


Anyone know which emulators these might be, so that I can file a bug should Holy Mapperel fail?

Again, the biggest reason to stick with MMC1 is if your cart manufacturer charges more for the larger CPLD that can hold an MMC3. Have you received quotes from manufacturers?

Animated backgrounds don't technically need MMC3, as you can stuff tiles into CHR RAM during idle vblank time. The Curse of Possum Hollow does this because only 16 tiles of each background can be animated (in 2 groups of 8, one group per vblank).

If that doesn't cause any supply or cost issues, I think that's a great decision.


Some may associate "raster effects" with "parallax effects", but dialog boxes and status bars are also considered raster effects. Maybe you'll think of something else to do in-game.


Those are always pretty cool.

We already have had a discussion about this exact same subject 2 weeks ago. Please research before asking.

I mean the textbook definition of "overloaded" in a programming context.


I haven't tested it, but this comment in FCEUX's source is suggestive.

Do you remember when I told you that you have a habit of trying to put me down? This is another one of those examples.

Do you seriously expect me to find a single post within a larger thread that is called "More MMC1 CHR bankswitching woes" when I have a question about increasing the number of PRG ROM banks of an MMC-1 ROM?

Yeah, sounds doable. I always read every post in every thread on this forum. How could I not stumble upon this information buried in a thread about CHR-related issues?

Based on my reading of that code, it still figures offs_16banks correctly, though artifacts from using 4K mode with different values for bit 4 might not be emulated. I just tested a Holy Mapperel SUROM build in FCEUX and confirmed that it worked. I think the comment was just describing misuse of the WRAM disable bit as an extra PRG bank bit.

I originally didn't intend to answer, as I don't necessarly like getting political, but as it seems from DRW's signature he's selling games I can't refrain from commenting. We the forum users help everyone for free, and you are probably making profit from this help, but you still complain and act relatively aggressively. This behavior is not inclining people to help you. Now I can already forsee you aggressively defend your cause and so on, but I just won't care; I'm just pointing things out, I don't care about being right or wrong or anything, and I don't like getting political anymore.


I don't know why you're taking it personally, but I don't normally behave differently towads different forum users. I would have said the exact same with anyone else. If you are taking this as a personal attack or anything you're probably paranoid, since this is neither personal nor an attack. I simply wrote a helpful post about extensions of MMC1 less than a month ago, I'm linking to it (and other people discussing the subject) rather than typing everything down again. How's that bad in any way ? Sometimes if I clearly remember a discussion having already taken place I could even link to post from 10 years ago too. There's no point in discussing the same thing over and over again if a clear explanation is already there for free.

Besides, you mentioned your game doesn't start but you didn't explain the efforts you made debugging with FCEU or Nintendulator in order to see where your game crashed, so not pointing to the reail problem.


Yes, I expect people to follow the forums, but I fully agree the thread title is irrelevant to the subject being discussed in this case; this happens regularly though and is unavoidable as discussions tends to derail.

I don't complain about people who help me. But I can complain about snarky comments that don't help me.

I'm grateful for rainwarrior's and tokumaru's help because they told me exactly what the issue is.
You, on the other hand, merely told me "Please research before asking." And your link merely repeated what has already been answered by the ther two guys, so I didn't even need this link in that moment anymore. Hence, your help in this situation was exactly zero.

My gratefulness always depends on the actual contents of the posts. Just because person A helped me doesn't mean that I have to be grateful towards person B, you know?


Linking to another thread is fine. Complaining that the poster should have found it himself isn't, especially when it's not even obvious that this specific thread is about this specific topic.


And that's a problem why exactly?
Sure, if someone does some obscure things in his code, then you can ask him what exactly he did. But I merely added more banks and someone immediately recognized that MMC1 simply doesn't support this number of banks, period.
So, what exactly are you even complaining about? That I didn't list all the things that I've done that wouldn't have made a difference anyway?

Again: My problem's answer lies not in any code bugs that I accidentally made, but in the simple fact that the mapper isn't built for that size.
The wiki page says 512 KB and you write five bits to the mapper, but the 512 KB only refers to some hacky workaround of which I never even knew that it can be a thing in the first place. So, my confusion after trying to add more banks and the game not working anymore wasn't something that was easily avoidable, but it was something that's easily answerable by anybody who knows a bit about the MMC1.


Oh, so you're not only expecting people to read every MMC1 thread because one of the 50 threads where this word appears might have this very answer. You expect people to read every thread because even a thread called "Scrolling issues" could have the desired MMC1 answer somewhere on page 17 of 25.
This premise is even more ridiculous.


And that's everything that I have to say about this.

Oh I totally did not understand that, this changes everything. I assumed you knew about SUROM quirck but couldn't make it work and asked how. So I was definitely wrong from the beginning - my apologizes.

Well, I explained in detail what I tried, didn't I?

This way, it was clear that I didn't know anything about any specific quirks and the unusual way to implement a 512 KB MMC1 ROM, but that I simply just tried to extend the game from 256 KB to 512 KB, in the same way that someone would extend a 128 KB MMC1 ROM to 256 KB.

Or, as you said it yourself:

If you have SNROM working, there are two ways to get SUROM going: one that "wastes" bank 15 by making it a duplicate of bank 31, and one that uses it efficiently. Making the most efficient use of SUROM requires figuring out a good separation between the data in banks 0-15 and in banks 16-31. This in turn needs a bit more knowledge of 1. assembly language, in case the C runtime can't be made to understand SUROM, and 2. how much space you plan to devote to different data types, such as background CHR, sprite CHR, maps, and scripts, so that code in bank 15 can be devoted to those data types.

Making a game larger than 256K on the Action 53 mapper has much the same issue, as writing the outer bank register is much like writing the MMC1's CHR bank register, just without the serial complication. But then this might not be quite as relevant to your particular case, as you wrote in another topic that you want to make your game use the same combination of mapper and ROM sizes as at least one game licensed by Nintendo. In this case, it looks like you're targeting Dragon Warrior III and Dragon Warrior IV.

Yeah, the 512 KB in MMC1 is a bit too hacky for me, even if two popular games used it.
So, I decided that I will use MMC3 for my new game from now on.

This has the advantage that I can use animated backgrounds, which is a thing that my graphics artist is very fond of.

Disadvantage: I can only switch the graphics in slices of 1 KB. I have to find a good way to load weapon graphics when changing the weapon in the menu.
In MMC1, I could simply load the ~20 tiles of the active weapon. But not anymore.

Sounds like you are using CHR-RAM with MMC1, and you could do that that with MMC3 also. That's the best of both worlds, you can switch 1kB pages and also update individual tiles. 32kB CHR-RAM is the usual size these days. The mapper itself doesn't affect what type of CHR memory you can use (ROM, RAM, or Flash), but the specific layout of the board does, so you would need to confirm with your board supplier.

DRW wants to use the same combination of memory sizes as a licensed donor, if this post is any indication.

Just to reiterate, there were still a bunch of games released on TNROM and TGROM, with 8 KiB CHR RAM, and that hardware still supports bankswitching the CHR RAM.

Yes, you're limited to figuring out how to usefully get bankswitching animations with only 8 KiB of CHR, but that's the only constraint. It still provides all the advantages of CHR RAM.

Lagrange Point made extensive use of being able to bankswitch just 8 KiB of CHR RAM.

As far as I understood it, there was no actual licensed game that used bankable CHR RAM with MMC3.
And as tepples already said, I only want to use stuff that was also used back in the day, not things that are only used in homebrews.

(Furthermore, I will probably only ever use the most common mappers/boards: NROM, CNROM, UNROM, MMC1, MMC3. No VRC7 or MMC5 for me.)

Besides, the intention to only use stuff that existed does not refer to the combination of ROM and RAM chip in the MMC3 mapper.
If I used, let's say, 64 KB for PRG and 256 KB for CHR and there is no game that actually uses this combination, this would still be fine because the two MMC3 chips are independent by definition.
There are 30 different combinations of these two chips and if my specific combination wasn't used by any game, then this is still alright because the mapper was designed to be able to combine both chips accordingly. As long as each individual size of each chip was used in any licensed MMC3 game, that's alright.

But CHR RAM + bankable CHR, that's a whole new category. As is a 512 KB UNROM mapper. Those things simply didn't exist back then, so I don't want to use them.

Are ... you just not reading what I'm saying?

All MMC3 support banking their CHR. Always. Even when it's RAM.

The only constraint is that no contemporary boards used more than 8 KiB of CHR-RAM, regardless of mapper. (Deliberately excluding Racermate, Videomation, and Oeka Kids)

The only boards that don't support banking its CHR when it's RAM instead of ROM are rare Famicom-only Bandai mappers (153 and 157). Even MMC1-using boards, where being able to bankswitch only 8 KiB of CHR is more-or-less useless, still supports banking CHR RAM.

CHR (RAM or ROM) is *always* bankable on MMC3. What licensed gamed didn't have was more than 8KB of CHR-RAM. Games could still switch those 8KB around, hide some of it by mapping another part to more than one slot, things like that... The usefulness of that is debatable, sure, but it's possible nonetheless. As pointed out above, Lagrange Point does it.

O.k., it looks like I didn't quite get the concept of banking 8 KB before.
(It looks like in my subconsciousness, it was still the idea that one bank = the size of one NROM chip, i.e. 16 KB for PRG and 8 KB for CHR.)

But yeah, since you can bank in 1 KB steps, this might be a possibility:

Draw your background graphics to the CHR RAM chip four times: Static tiles are repeated in every KB, animated tiles are drawn in their different animation phases in each KB.

Then choose each of these four KBs to be displayed as the active bank to create the tile animation.

Am I understanding this correctly?

If yes:
Well, it's doable. But this basically limits your background graphics to 64 tiles if you want four animation phases, doesn't it?

Did any game actually do this? Using MMC3 with CHR RAM and actually using the banking function on its little 8 KB CHR chip?

I think you could, say for example use 16 tiles for animations and have 4 animation frames; those would be for examples tiles $00-$0f, $40-$4f, $80-$8f, $c0-$cf. The remaining tiles can be used for static tiles, except those of one bank that will be the one which is bankswitched. This gives you 3*(64-16) = 144 static tiles, located at for example $50-$7f, $90-$bf and $d0-$ff.

Then when doing animations you switch banks 0, 1, 2, 3, 0, 1, 2, 3 etc.... in slot 0, so that tiles $00-$3f mirror $40-$7f for animation frame 1, $80-$bf for animation frame 2 and $c0-$ff for animation frame 3. The problem is that tiles $10-$3f are de-facto unusable for neither animation or static tiles, so you effectively "loose" 48 tiles.

This is just an example of how bankswitched CHR-RAM could be of any use. This wasn't used back in the day (except for Lagrange Point) so I wouldn't consider this the truly "NES authentic" to do it, but since the hardware allows for it without any improvement this is debatable.

You could also use only 2 or 3 animations frame in order to get more static tiles, it's a tradeoff; you still loose 64-N tiles in all cases, where N is the # of animated tiles.

You can also use CHR-RAM the regular way and animate the tiles by VRAM updates, splitting the updates in several frames if needed. In most cases this is acceptable, but sometimes it will look weird to not have all animated tiles switching at the same time.

Also while we're talking on the topic, I can't think of any usefulness of neither MMC1-style 4kb CHR-RAM banking, as it is equivalent to $2000.3 or $2000.4 switching, so it's a redundant feature, unless I'm forgetting something. I also have trouble finding an usage of bankswitching CHR-RAM for sprites, but this could be useful when doing it mid-frame for drawing sprites partly from one bank and partly from another. Maybe interesting effects could be done this way.

This is just a software technique using the available hardware though... if a programmer starts banning software techniques just because they haven't been programmed before, then his games won't be original at all, will they?

Bankswitching within a 8kb CHR-RAM is a hardware feature that have only seldom been used. In that regard, it is similar to other hardware features that have seldom been used such as 4-screen mirroring.

A game mixing and improving software techniques already used from various existing games is still going to be original. And yes indeed I said right from the start it would be controversial whether bankswitching within 8kb CHR-RAM is "authentic" or not. What is sure is that bankswitching more than 8kb of CHR-RAM is definitely not authentic.

It's authentic on CPROM and the Oeka Kids board. It could also be considered a predictable cost reduction of TQROM, which has MMC3 and 72 KiB of CHR memory, the last 8 KiB being RAM.

What I meant is that it's a programming trick using the hardware that's already available. Strictly speaking, everything is a hardware feature, since you can't make an NES game without the hardware (CPU, PPU, etc.). But once the hardware is set in stone (the console, the mapper, the controllers), everything you do from there is software. Cleverly using the hardware that's available to you is different from throwing in new hardware to solve a problem.

You can search for MMC3 + CHR-RAM on bootgod's database.

The primary candidates here are Mega Man 4 and 6. I don't think either of this does any CHR bankswitching, but that's a research question that more or less requires playing through both games with a debugger open. (It could easily have been relevant for some animated nametable boss, for example.)

To be honest, most early/innacurate emus probably emulate a plain solid 8k of CHR-RAM when encountering any game with CHR-RAM, so they don't emulate the bankswitching. If MM4 or MM6 would have used this feature, it would have been discovered long ago simply by playing those games in old emulators.

For instance Romancia probably looks wrong in old emus for exactly that reason (I'm saying this from memory and this need to be verified).

However it's possible the games would use this by accident if some glitch is triggered or something, but I still think that's unlikely.

Yeah, my guess is also that they probably don't. Couldn't say about emulators, but FCEUX is definitely very ad-hoc about CHR-RAM, wouldn't trust it without a test. Kinda wonder whether it's even connected on the TGROM boards, but I don't feel like trying to trace that out from photos at the moment. (If DRW is interested they can do the research.)

Interestingly, all three US TGROM games do set up the banks explicitly, and with different code for each (not hugely different, but they're even storing from different registers, so it doesn't feel like an "MMC3 copy paste").

The Wiki TxROM page says that TGROM could have CHR RAM or ROM, but I only see RAM entries in bootgod's db?

Nintendo always connected the banking lines.

(Looking at http://bootgod.dyndns.org:7777/profile.php?id=1073 you can see CHR A11 leave the MMC3 and go via a series of traces and vias to the CHR RAM)

Then cartidge pirates were unaware too, because in "Rockman 7-in-1" and "Rockman 6 in 1" (different manufacturers), which have MMC3 glob, CHR-ROM and CHR-RAM, A10-A12 of RAM is connected to PPU A10-A12.

For the majority of games (not that there are many CHR-RAM games using ASIC mappers, but still) that probably works, but it's wrong.

I could be wrong but my guess would be the reason more than 8k was not used is maybe that it was not cost effective at the time? In 2018, it shouldn't be an issue so I think that unless the hardware doesn't support it (which is not the case) and you need a new mapper, I don't see why I you should avoid more than 8k. I would do if I really needed it on any project.

With more memory like 32k, you could buffer a lot of sprite in any way you want and make you life easier. I guess all kind of animation too. And if it doesn't work on current emulator then they are not emulating properly (the hardware can bank any chip, ram or rom, it should make not difference) and must be updated someday. I don't see any problem with that.

That's exactly the reason why I myself wouldn't do it if my plan is to create a game with authentic 80s to 90s hardware: If it wasn't cost-effective back then and was therefore never done, then I will not use it.

Software tricks are fine, like 8 KB bankswitching, even if nobody on MMC3 ever did this. Because this has nothing to do with limitations, but with a single person's creativity.

That's also the reason why I used sprite 0 and the sprite overflow flag for "City Trouble" to create parallax scrolling and a status bar, even though nobody ever used it like that: The techniques are there. A programmer from 1986 could have done this without asking Nintendo to produce special hardware.

But hardware constellations that didn't exist for various reasons (like putting a 32 KB RAM chip into the game due to costs): I would only do this if I tried to create a modern game on the NES, but not if my game is written in the spirit of old games.

So, if I ever created a game based on "Buffy the Vampire Slayer", then everything would be allowed because who knows what boards they would have had if the NES had still been strong in 1998.
But a 1991-style action adventure only gets hardware that was available and common in 1991.


And since 8 KB CHR RAM banking doesn't seem so great to me, I settled for regular MMC3 CHR ROM with many banks now (probably 128 KB if my calculations are correct).

That makes sense, it's a way to assess how far people have come with reverse-engineering the hardware if you try to stick to the same limits on hardware as developer X, but you are still able to do more thanks to discoveries since then, and more time to spend on managing the available resources better. For example the first Mega Man game uses CHR-RAM (standard UNROM board) but the developers never thought about uploading tiles during VBlank for animation.

Sprite overflow was used by Bee 52, but I don't think a single commercially released game ever used the DMC IRQ for raster timing. Today, these are perfectly viable and documented ways of getting more out of a stock NES than many devs had a chance to back in the day. Sloppy documentation was a common thing for them, many stories have emerged where people did not use DPCM samples simply because they had no idea the 5th channel even existed.

Not even Fire Hawk (unlicensed) and Time Lord (licensed)?

Re: above: https://wiki.nesdev.com/w/index.php/Tri ... late_games

To each his own, but I find that kind of self imposed limitations silly. There are much more effective ways to capture "the spirit of old games" than having technical guidelines which will restrict your output in ways only yourself will notice. The 2018 end user who is playing a NES game that was definitely made in 2018 and not 198X won't be able to tell the difference or care if you're using CHR-RAM or doing MMC1 CHR bankswitch or any other hardware aided technique, but he WILL notice its art style, game mechanics, etc.

The difference in capabilities between 32k CHR-RAM and banked CHR-ROM are pretty academic. It's not really a significant difference, IMO. This is nothing like getting 8x8 attributes or stuff like that, it's more or less the same as we were already able to do in common NES games.

The more significant thing is whether crusty old emulators will support it, or possibly whether you want to build it with donor carts. Both of these could be an issue, depending on your priorities.

In terms of building the hardware, I think at some point the price of 32k SRAM became the same or lower than 8k, so even for carts that only needed 8k it was more sensible to use the 32k part anyway.

Just to say I fully adhere to this philosophy, and I always try to do thing the good old way whenever possible. That's also why I'd use the smallest mapper that can do what I want to do when offered the option. If you don't want to stick to the old standard, there's no point in writing a game for the NES, you could just write it for modern hardware using retro audio and graphics.

I even go further as I'm even reluctant to use software tricks that wouldn't have been used back in the day, although if they are useful for a game I'd use them but only when there's no other option. In this particular case I'd only use bankswitching withing 8k of CHR-RAM if the effect I want to be done can only be done that way and cannot be mimicked with "normal" CHR-RAM updates.


There's actually a huge difference in the sense that CHR-RAM is flexible and allows for special graphical effects unthinkable with CHR-ROM, such as making tiles disappear gradually. So if you can both do those "CHR-RAM only" effects and quickly bankswitch fresh tiles in for new animations, I mean it's borderline bypassing NES' technical limitations. I know the NES can do it but not with hardware commonly released with games back then.

The most beautiful hardware doing this is the board for Napoleon Senki, it was magnificently designed and uses 74xx series chips very cleverly to provide four name tables and advantages of both CHR-RAM and CHR-ROM. Unfortunately the game sucks very hard.

CHR-RAM effects like gradually changing tiles was certainly done in some pretty common games. CHR-RAM was very common in general (25% of games in the database). We're just proposing the option to do both (or one or neither) on the same cart. This is just about the tiniest augmentation of "NES technical limitations" I could imagine.

.... The entire point of what I've been pointing out is that that's exactly what was possible using "hardware commonly released with games back then".

Did TNROM and TGROM games use it? At least Megaman 4 and 6 clearly don't, because pirates didn't wire it up. But that doesn't mean it wasn't supported, and it's obnoxious to claim otherwise.

DRW's conclusion that he couldn't figure out how to usefully use bankswitching with just 8 KiB of CHR RAM, and therefore he'd rather use a larger CHR ROM? That's fine, that's a perfectly valid conclusion. But once one is using CHR RAM bankswitching is already there and you get it for free.

Apparently I got misunderstood. Of course using CHR-RAM was done back in the day and I'd do it today for doing a retro game. What I meant is that using both CHR-RAM and more than 8kb of it, allowing for animated tiles, was not done back in the day. So if you have *both* CHR-RAM only effects and animated tiles, that's not quite truly retro.

@DRW and @bregalad

To each is own but making game on retro hardware is retro enough, no need to limit yourself if the hardware allows it. It's like you guys like pain and just need more or it and need to constrains yourself for some masochistic reason (all in jest, I know you guys seems serious about it).

It depends on what the retro hardware allows. If I do a game that could go on an existing donor cartridge, them I'm doing the stuff that the hardware allows.
If I use a RAM chip of a size that never existed back then, then where is the limit?

In this case, I could create a PowerPak-like cartridge that works with a flash drive, on which I put a dozen NES ROMs. Then I program the cartridge to load the ROMs in sequence.
I.e if you reach a certain point on the one ROM, the game triggers some kind of a reset and the cartridge software loads the next ROM as if it was loading a new level of the same game.
This would allow me to create NES games with unlimited size that still work on the unaltered console hardware.


Besides, I don't limit myself because of masochistic reasons. I limit myself, so that I can say that this is an authentic game that could have been created back in the day. "City Trouble" is something that could have come out in 1986. A time traveler could go back to 1986 and give the ROM to a publisher and the game could be released exactly as it was written now.

You know, simply programming a PC game with a retro look is not enough for me.
It has to be the real console, so that I can say: "This adventure game, that's something that could have been produced back in 1991 when "Final Fantasy" and "A Link to the Past" were popular."
If I use a new hardware configuration that didn't exist at all in commercial games, there goes the whole "this is really authentic for the 80s/90s" argument.
In this case, what prevents me from buiding a Rhaspberry Pi into an NES cartridge and simply routing the PC game's output to the NES' PPU?

@DRW

I was just pulling your leg and it did work (the "in jest" comment was about that) You are free to apply any limitation you want if that is your personal goal.

As for myself, if just adding a bigger ram chip would make my life easier on a project, I would since the nes allow it. Would I add an FPGA that change completely how the nes work? No, I wouldn't, it not a nes anymore. Would I make a mapper that help solve a memory issue? Maybe, it it doesn't change the nes behavior and just help programming memory.

So everything is relative. I'm open minded bout that part. So many thing could have been done on the nes in the past if they could have made affordable memory mapper for that. If the VRC6 could have been usable on the american nes that would have been nice for the audio part for example.

By the way, if I created a game based on a movie that's of a younger date, then I would use more advanced techniques as well. Because there's simply no point in trying to pretend that a game about "Star Wars - The Force Awakens" came out in the 80s.

But for my current games, I even include a fake production story into the manual.

For "City Trouble", it was the idea that we went to the United States in winter of 1985 to have a look at the arcade scene to get some inspiration for our first home computer game. There, we discovered the NES in a mall. Since those games were better than anything we've seen on home computers, we decided to create our game for the NES. One year later, "City Trouble" came out.

For the adventure game, it will be the story of creating an NES game in 1992 with a graphics style similar to "Final Fantasy", gameplay similar to "Zelda I" (screen by screen scrolling) and "III" (diagonal movement), and with plot buildup like in "Final Fantasy Adventure" where the whole story moves along as you play, instead of simply giving you an initial task of going through all the dungeons (which even "A Link to the Past" is guilty of).

I'm wondering if you're a stickler about using UV EPROM instead of EEPROM too? That wouldn't have been used in the 80s either, and I'd argue that the difference in capability (saves without battery) is much more significant.

The difference between using banked CHR-RAM and either unbanked CHR-RAM or banked CHR-ROM is pretty insignificant. Like if you think it would be unfair to have both a dissolving letters effect, and flipbook background animations... just don't use one of those two effects and you're effectively obeying the "limits" of either thing, if you really care about that specific distinction.

Otherwise both kinds of effect are well within the "normal" range of NES effects that games did use. I was really puzzled at this being called a "huge" difference by bregalad; there was no misunderstanding of his words, I just really don't get the severity being assigned to it. I think it's about as trivial a discrepancy as it gets with these things.

... I thought his point about "not going to use more than 8 KiB of CHR-RAM" was defensible? At least, I think we made it clear that CHR RAM banking was definitely supported, even when there was only 8 KiB of it.

I suppose on some level, the real question is "how much more expensive was a 32 KiB SRAM than an 8 KiB SRAM in 1991?" Generically, we know that prices have been dropping by a factor of 10 every 5 years, but that doesn't say anything about specific relative prices of two similar parts at the same time, or when any given product falls out. And the only information I've been able to find so far is this catalog from Allied Electronics in 1981 (≈$10/1kibit) and this catalog for Atari parts from the mid 1980s (≈$3/2KiB)

To me, it's only about the game itself.

If you use hardware that didn't exist back then, but where the game's ROM is still built in a way that it would work on an old donor cartridge, then it's fine to me.

After all, we don't use the original hardware parts anyway. My game's board is blue instead of green, it uses a third party multi-region lockout chip etc.

So, if you program a standard save capability into your game and then you use a modern flash memory chip instead of the old battery-backed RAM, this is fine because the gaming experience is still the same and the programmer still adhered to the authentic rules.
You're using more reliable hardware, but a time traveller could still sell the game to a 90s company and you could still grab a donor cartridge and put it there.

The ROM file and therefore 100 % of the gaming experience is still authentic. The NES' output still produces exactly the same that it would have produced back then. You're merely protecting yourself from real-worl hardware quirks that don't have to do with the gaming itself anyway (like batteries that can get empty).

Of course, if you use modern hardware to do things that weren't possible back then, like implementing the PRG ROM as a flash drive, so that you can use the PRG ROM as additional RAM, that's out of the question again.

But yeah, my idea of authenticity does not refer to every single hardware part, only to the fact that the hardware doesn't do anything that the old stuff couldn't do and that the game could still have gone on an authentic cartridge.

Just like you're still an authentic MS-DOS programmer, even if you distribute your game on a USB stick, bundled with DOSBox, you're still an authentic NES programmer, even if this very implementation of your ROM uses flash memory for convenience.

TGROM existed in NES carts, as did 32K SRAM. Therefore a TGROM variant with 32K CHR RAM could have existed. So here's how to repro an INL-TGROM game using vintage parts from Famicom or NES games:

1. Program the ROM image onto a 512Kx8-bit NOR flash chip
2. Open a Mega Man 4 cart and an Oeka Kids: Anpanman no Hiragana Daisuki or Romance of the Three Kingdoms II cart
3. Replace the RAM with the 32Kx8 RAM from the second cart, rewiring based on the pinout difference between 6264 and 62256 SRAM
4. Replace the ROM with the flash chip, rewiring based on the pinout difference between mask ROM and flash

Ok, found a useful price reference.
This advertisement in the back of an october 1991 issue of a electronics projects magazine has the "EasyTech" corporation selling 2 KiB SRAMs for $2.25/@1 , 8 KiB for $3.75/@1 , and 32 KiB for $6.25/@1. Ignoring the volume discounts that Nintendo would have had, this would be an increase in cost of materials of $2.50 / cartridge, and standard retail markup would correspond to an increase of $10 on the retail price.

Obviously Nintendo got better volume prices than that, so the increment would be smaller.

Sorry for the late circle back, but I wanted to I wanted to share the data point since it was being asked earlier. The Japanese version of Destiny of an Emperor 2 uses CHR-RAM banking (at least the translation does) but I'm not sure if it's for animation purposes. At one point I played the game without supporting CHR-RAM banking at the opening cut scenes were glitched, I think a few other things during game play were as well.