NROM larger than 32K?

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Post Reply
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

NROM larger than 32K?

Post by Shiru »

A random question. Since there is some amount of address space below $8000, is it possible to make a cartridge without a mapper, with a 64K ROM chip that will be partially accessible? Of course, more than 16K of a 64K chip will be wasted, that would be unacceptable in 1980s, but today I think it can have some good use, given it wouldn't require too much extra hardware (otherwise a mapper could be used). More specifically, C programs would benefit from having few extra Ks of linear address space, this would allow to have more code and data without need to going low level to do bankswitching.

And a sub question. Are there mappers that have a fixed 32K bank and only switch ROM banks in the lower part of the address space, like $6000..$7fff?
tepples
Posts: 22862
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

To get 40 KiB of linear address space from $6000-$FFFF, you'd need to make a decoder that returns 0 when PRG /CE is low or when M2, A14, A13, and A12 are high. Such a circuit would look a lot like a PRG RAM decoder.

It's just that emulators don't support it because no licensed game from the early NES era uses this configuration. Licensed games were more likely to use CNROM and read back map data from unused CHR banks, like in Milon's Secret Castle. MMC2 switches $8000-$9FFF and leaves $A000-$FFFF fixed, but only one game ever used that. If you want to switch $6000-$7FFF and leave the rest of the address space fixed, and you want something compatible with emulators, your best bet is FME-7 (#69).
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

I read somewhere that MMC5 can use $4020...$5fff too. Is it correct?

Since APU registers are internal to the CPU, my wild guess was that you don't need to disable ROM for $4000..$401f. This would allow to have 48K, having pretty simple decoder that only disables first 16K of a 64K ROM, for addresses below $4000.
tepples
Posts: 22862
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

FDS and MMC5 put registers in that space. But if you want to decode all of $4020 to $5FFF, you need to bring all PRG address lines, A5 through A14, into the decoder. This becomes expensive to do with discrete logic, and by that point, you might as well use CNROM with CHR ROM readback.

Even if APU registers are internal to the CPU, you're still likely to get a bus conflict somewhere. Otherwise, we would probably have already seen such a simple decoder used by unlicensed commercial games.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

I have strong doubts about the 'we would probably seen it already' argument. The thing is that at the time when wasting 16K of a 64K ROM became acceptable (near the last days of NES, I think), quality standarts for NES games were really high, with much larger ROM sizes and complex mappers being widely used. So such small improvement could be simply unclaimed.
User avatar
Bregalad
Posts: 8115
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

I already tought about this. Super-NROM with 40kb of PRG ROM is most certainly possible, and would make a lot of sense today.

However, you have to think that back in 1986 to achieve this you'd need :
- a 32k PRG-ROM chip
- a 8k PRG-ROM chip
- a 74HCxxx chip to decode adress for the 8k PRG-ROM chip
- a 8k CHR-ROM chip

While CNROM would have more space overall with less chips, you understand while the overhead of bankswitching was cheaper than the overhead to decode adresses in $6000-$7ffff

Of course you could also get almost 48kb of ROM at $4018-$ffff, but the decoding would be even worse since it would be imperative to block all adresses $4000-$4017 to prevent conflicts with the CPU itself, and this would need several chips to decode.
Useless, lumbering half-wits don't scare us.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

The question - is it really needed to block $4000..$401f. I recall a discussion of the cloned APUs with switched duty cycle values, with the problem that we can't write APU registers outside of the chip (to use it in a HW player and put corrected data there with some other CPU). I guess there will be no side effects for writes into the area if ROM is enabled. There is only one readable register in the area, and we can put certain values into the ROM at the location to make bus conflict (if it is there) predictable.

I don't know the HW well, so I would like to hear from people who really know that stuff, if this correct and if this doable.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

My guess is programmers got over the 32KB hump early by bankswitching so they never considered this because they always used bankswitching and it works. That and mainly Nintendo never offered such a mapper so it was basically a non-option. That and they weren't coding in C like yourself so it might not have been as much of an issue for them as it is you.

The $4020 to $5FFF is basically a non-option based on how many inputs you need. You could do it but with that many pins why not do something more useful. It gets messy to do with discrete ICs which is probably another reason it was never done. One could come up with a discrete design but it's so much easier and defiently more versatile to use a $1-2 CPLD IMO. You could even bankswitch the $6000-7fff between two 16KB pages so you'd have an opportunity to make use of that space. Although it kinda defeats your goal of having more fixed banks...
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

I don't have any issues with programming in C and/or bankswitching. I don't have any goals here. I just have a simple random idea that could be handy if it is possible to implement.

Currently it is narrowed down to the question: do we really need to block the area $4000..401f? What kind of problem is there if it is not blocked?
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

Shiru wrote:Currently it is narrowed down to the question: do we really need to block the area $4000..401f? What kind of problem is there if it is not blocked?
Your controllers and sound wouldn't work...

EDIT: you'd end up with bus conflicts and you'd basically the ROM would be fighting to read/write a different value than desired. So assuming the ROM would win a few of the bus contentions the sound and controllers would be broke.

EDIT 2: (sorry it took me a bit to realize I was ninja'd)
I guess there will be no side effects for writes into the area if ROM is enabled.
It depends, you'd have to disable the ROM during writes to prevent bus conflicts which is not normally done with 'NROM' but you could add the logic to do so fairly easily.
There is only one readable register in the area, and we can put certain values into the ROM at the location to make bus conflict (if it is there) predictable.
This is the problem, you can't change or move the value around in ROM. It'll ALWAYS be the value you burn in there. So if you enable both the ROM and the single readable register you'll have the two conflicting who knows what you'll get. You have to block the ROM from outputting at this location.

EDIT 3: (the more the merrier)
Actually there are two registers if you want two controllers...
lidnariq
Site Admin
Posts: 11636
Joined: Sun Apr 13, 2008 11:12 am

Post by lidnariq »

To expand on what infiniteneslives said, it will work iff you disable ROM on writes and reading from $4015 - $4017. The former is necessary to not cause bus conflicts when writing the sound registers; the latter is necessary to be able to read the joysticks and the $4015 sound status register.

Could you build something that will take all 18 control lines and enable ROM for every single bus-conflict-free address? Yes. a 20v8 PAL is probably the most straight-forward way. But I'm not clear on the utility of having the 21 bytes below $4015 contain ROM, since it's not contiguous.

Could you also put resistors in series with the data lines of the ROM so that the CPU's internal peripherals always win bus conflicts? Probably, but you might run into timing issues.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

Oh, I have forgot about the controller registers in this area.

Well, I have a ridiculous 'waste'-style solution on the ROM blocking: throw in an extra ROM. I.e. two 64K ROMs, address lines are connected together. The extra ROM contains flags for every single byte of the address space that enables or disables PRG ROM per location. Since we don't need lowest 5 bits, we can use a 2K ROM as the extra ROM. Of course, this is more like a fun thing to think of, not a very practical solution, but should be doable.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

HUH?

If I think I understand what you're trying to explain the huge amount of logic needed to decode that 'flag' rom would be huge. It sounds like a lot more of a waste of decoding/enabling logic and processing than ROM. aka most complex solution you can brew up for a simple task...
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

No logic would be required, just three ROMs - PRG, CHR, and the extra ROM. The extra ROM would be basically 9th bit ('enable') for every byte of PRG, like D0 of the extra ROM connected to OE or CS of the PRG ROM.

Actually, it starts to look not that impractical, because price of the ROM chip is comparable with a CPLD, but you don't need extra tools to program that ROM, unlike CPLD.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

How are the two roms connected to each other?

If you use anything smaller than the PRG ROM you'd need a large amount of logic to decode the 'flag' rom. Basically to use 2KB like you suggested you'd need a large CPLD and/or some sort of processor.

If you used 64KB PRG ROM and 64 KB 'flag' rom then maybe you could use the D0 (or any single data line) to drive /OE of the PRG ROM. That wouldn't necessarily require large amounts of logic. But 64KB of ROM at ~1.50 is still about the same price as a $1.20 CPLD and voltage regulator. You also need a larger PCB for your solution (more $ generally). But yes you wouldn't need a JTAG programmer for your solution.

Either way your solution is crazy though IMO ;)
Post Reply