NROM larger than 32K?

[80sFREAK]

What was the first purpose - get more room for code or get some sort emulator-protection?

If you can't find the answer to that question in this thread I would imagine your question is impossible to answer.

I can see tons of flame and problem to emulate non-standart hardware. Bank switching is an idea, going thru whole 8-bit computers epoche and nothing wrong with it. Yeah, code a bit tricky(if you want to use banks for executable), but nothing is impossible.

Main disadvantage of this mapper is no "save mode" or either you have to "hide" some RAM under mirrored system RAM

[Shiru]

I had zero previous experience with FCEUX and was able to add the support for the mapper in a few hours. So no problem there.

Linear memory model predates use of bankswitched memory in 8-bit computers. It is only seems 'crazy' for people who get used to the NES design too much, I think.

I don't think there are too many NROM homebrews that use save RAM, so this problem does not seem too large. Also, no one forces to use the mapper if someone needs save RAM, or more ROM, or anything else. It does not replace anything.

[infiniteneslives]

Bank switching is an idea

Why didn't we think of that idea??? Yes! Now all our problems, they are solved.

EDIT: Sorry, to understand my sarcasm I assumed you had actually read a few posts on this thread. Your like the 4-5th person to present bank switching as a solution, when avoiding bank switching was the POINT.

Q: How do I get to China without flying?
A: Buy a plane ticket and fly there.

[tokumaru]

Your like the 4-5th person to present bank switching as a solution

That alone should serve as an indication of how crazy this whole idea is, don't you think?

I still barely see the point in this extension, but I'm not against you trying to make it work. If someone does find that a slightly expanded NROM is better for their project than the most common/simple mappers, great for them.

I will problably never use it though, because I really don't like the CHR-ROM constraints of NROM. Even for really small projects I'd rather go with UNROM.

Like it's been said, nobody is forcing anyone to use specific boards on their projects, so the existence this extension isn't a problem at all. Don't like it, don't use it, like tons of weird mappers out there.

[infiniteneslives]

That alone should serve as an indication of how crazy this whole idea is, don't you think?

No I think it's just ignorant and annoying.

[cpow]

That alone should serve as an indication of how crazy this whole idea is, don't you think?

No I think it's just ignorant and annoying.

I'm so loosing track of who's on what side. Can we please calm the "you're nuts" replies down so the thread can return to its original topic?

[Dwedit]

Make bank switching less painful, then you won't need crazy chip select stuff everywhere.

[lidnariq]

The problem is that dealing with bank switching in CC65 is painful. There are two solutions, the EE solution and the programmer solution. The EE solution is "increase the linear range to 46kB", and can be implemented with a single 74 series chip that costs 18c in single quantities from Mouser. Yes, it's stopgap, but it does in fact solve the problem as outlined. It also doesn't pose any problems for future-proofing — it is not contradictory to any other existing hardware, and "here's 48kB of PRG" couldn't mean anything else.*

The programmer solution is fixing CC65. While this is not hard it is a huge time sink, and since no one has mentioned that they're now investing effort into fixing CC65, I just don't understand the nay-sayers.**

It's not even like one'd need to do this the really hard way with the aforementioned call graph: you could implement something like Borland Turbo C++'s Medium (bankswitched code, no bankswitched data, one trampoline in fixed bank, all calls involve bankswitch) or Compact (bankswitched data, no bankswitched code, all data fetches involve bankswitch) memory models.

But I'm not volunteering, and until one of you do, I'm going to stick by the EE solution.

*Someone's going to bring up the "why is it 48kB-2kB instead of 48kB-24 bytes?" complaint I read earlier. Answer: because the hardware implementation is the important implementation. Emulators could implement the full window but the concern is that would encourage the development of programs that would require significantly more expensive hardware.

**If a programmer in your employ came up to you and said "Boss, I'm having problems writing bigger games and $simple_change would help me," that your reaction is No! You're going to use the same tools everyone else does! — well, it makes me glad I don't work for you.

[infiniteneslives]

Well said lidnariq I fully agree.

[80sFREAK]

The problem is that dealing with bank switching in CC65 is painful. There are two solutions, the EE solution and the programmer solution. The EE solution is "increase the linear range to 46kB", and can be implemented with a single 74 series chip that costs 18c in single quantities from Mouser. Yes, it's stopgap, but it does in fact solve the problem as outlined. It also doesn't pose any problems for future-proofing — it is not contradictory to any other existing hardware, and "here's 48kB of PRG" couldn't mean anything else.*

The programmer solution is fixing CC65. While this is not hard it is a huge time sink, and since no one has mentioned that they're now investing effort into fixing CC65, I just don't understand the nay-sayers.**

It's not even like one'd need to do this the really hard way with the aforementioned call graph: you could implement something like Borland Turbo C++'s Medium (bankswitched code, no bankswitched data, one trampoline in fixed bank, all calls involve bankswitch) or Compact (bankswitched data, no bankswitched code, all data fetches involve bankswitch) memory models.

But I'm not volunteering, and until one of you do, I'm going to stick by the EE solution.

*Someone's going to bring up the "why is it 48kB-2kB instead of 48kB-24 bytes?" complaint I read earlier. Answer: because the hardware implementation is the important implementation. Emulators could implement the full window but the concern is that would encourage the development of programs that would require significantly more expensive hardware.

**If a programmer in your employ came up to you and said "Boss, I'm having problems writing bigger games and $simple_change would help me," that your reaction is No! You're going to use the same tools everyone else does! — well, it makes me glad I don't work for you.

I am fine with 46kB linear memory.
*48kB-2kB is good compromize
**As a boss i would ask, "how it will affect budget?"

2 infiniteneslives If you don't have sea sickness buy ferry ticket

2 cpow treat it as drinking and fighting in a pub, then drinking again together with folks, who made your nose bleeding

[cpow]

2 cpow treat it as drinking and fighting in a pub, then drinking again together with folks, who made your nose bleeding

I'll drink to that!

[nocash]

I just checked the http://wiki.nesdev.com/w/index.php/NROM-368 page. It does currently say that NROM-368 can be used for all mappers incapable of banking PRG, such as discrete logic mappers 0 (NROM), 3 (CNROM), 13 (CPROM), 99 (Vs. System), and 184 (Sunsoft 1).

For mapper 99, that's wrong. VS Gumshoe uses Mapper 99 for accessing 40K PRG-ROM (rounded up to 48K in iNES images). The game shares 4016h.bit2 for both selecting a 8K CHR-ROM bank, and simultaneously selecting a 8K PRG-ROM bank.

I'll remove Mapper 99 from list of the NROM-368 compatible mappers (on the wiki).
If there are other NROM-368 docs elsewhere, please fix them, too.
If anybody has already made a NROM-368 game for the VS system, please add some warnings about the problem (to the wiki, and to this thread, and to whom else you might want to warn).

[tepples]

We now have a page for the 7485's pinout, based on a datasheet. Does anyone feel like clarifying how A14-A11, M2, and /PRGSEL are routed through this chip?

[zzo38]

...to have a reason to put the support into official FCEUX and other emulators.

This is also one reason why I defined mapper 768 submapper 0; hopefully it can be used to run a mapper VM code, in order to test new mappers you make up without modifying the emulator.

[rainwarrior]

lidnariq: It's true that CC65 has no built in support for bankswitching, but it's not true that you can't do it without modifying CC65 itself.

- The easiest way by far is to only place your C code in a single bank, and use the other banks only for data and assembly code. (The simplest way to do this is with AxROM/BNROM and no DPCM samples. This gives you a full 32k to devote entirely to C code, and up to 224k for other things too! It's also a "one chip" mapper, no more complicated than the 48k NROM.)

- If you need C code in more than one bank, you can manage a small trampoline in assembly to transition between the banks. Each bank should be linked separately and combined at the end. You will need to link the CRT into both banks, and also remember to reserve enough RAM area for each bank's static variables (this can be policed fairly easily by the linker config for each bank). Also, make sure your startup code does the initialization for all the banks that need it.

Maybe it's true that this is too advanced for someone who wants to only write in C, but it really doesn't require rewriting/modifying the compiler to accomplish! The only thing that would require doing that is if you want transparent native bankswitching in C. If you're willing to organize your code and write a little bit of assembly, it's quite doable.


This said, I'm not offering this as a counter-argument to oversize NROM, which I think is fine. I just wanted to respond to the idea that bankswitching is somehow unfeasible in CC65.