NROM larger than 32K?

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

Moderator: Moderators

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

Post by Shiru »

No extra logic for 2K 'flag' ROM is needed. Address lines of two ROMs could be simply connected to each other with a shift of 5 lines (A0 of 'flag' ROM to A5 of the PRG). We'll have one byte of the flag ROM as enable for 32 bytes block of the PRG ROM.

'Crazy' solutions like this were popular in early 1990s in hobbyist electronics, and this is very simple one comparing to some I saw, like PAL encoder with signal waveforms stored in a ROM.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

Ahh I think I understand how you'd connect the 2KB ROM up now. I didn't get the idea of shifting it to control 32byte chunks.

In that case you're looking at more like $0.40 for the decode flag rom.

With that I'd consider your design INTERESTING vice CRAZY... :)
Bananmos
Posts: 552
Joined: Wed Mar 09, 2005 9:08 am
Contact:

Post by Bananmos »

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?
I believe if you filled your ROM with $FF values for all those values, it might give the correct results in a NES system if you use NMOS-based memory in your cart, since NMOS technology causes 0s to 'win' over 1s, functionally giving a binary and. Of course, this might give totally different results on a clone system where the CPU is not an NMOS 6502.

...but as other have pointed out here before, even if it works it might be a bad thing to do, as this could create more wear on the circuits.

Then again, I guess the same thing might apply to unofficial 6502 opcodes like SAX (and A and X and store result), and I've never seen any recommendations against using those based on electrical wear, only compatibility. Maybe try building this cart and run it for a year's time to prove it's safe enough? :)
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

'0' wins because N-Channel transistors, used to connect an electrical line to the 0V, are stronger than P-Channel transistors, used to connect to +5V.

Therefore, in any technology, the '0' should always win, unless your technology uses oversized P-Channel transistors, which is unlikely to happen.

Back to the subject I think NROM, and any non-bankswitched mapper could easily be extended to 40kb, the problem is the iNES header only allowing for 16kb increment.

Therefore, 40kb can happen in hardware but now on iNES, but 48kb can exist on iNES, but not in hardware because of the sound/control regs.

Conclusion -> it's better to move to use a mapper if you really can't make things fit in 32kb.
Useless, lumbering half-wits don't scare us.
User avatar
infiniteneslives
Posts: 2104
Joined: Mon Apr 04, 2011 11:49 am
Location: WhereverIparkIt, USA
Contact:

Post by infiniteneslives »

Bananmos wrote: Maybe try building this cart and run it for a year's time to prove it's safe enough? :)
You can run it on your system for a year :)

Personally I wouldn't touch anything that intentionally causes bus conflicts with a 10ft pole. Just plan BAD design. Shiru's proposal prevents this while it's not conventional it's logically sound so it's just an interesting yet valid solution.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

Bregalad, did you read few posts above? There is a fun, but viable solution with three ROMs that allows increase of 16K.

No mappers increase linear address space of PRG, and it is a nice thing to have with existing HLL dev tools.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Post by lidnariq »

Or, although it's nowhere near as much fun, you could use a 74'238 or 74'239 to get a 46kB aperture.
User avatar
Bregalad
Posts: 8055
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

There is no need for such an EPROM.

You can always have your adress decoded like :
/OE = M2 * !A14 * !/ROMSEL * (A9 + A8 + A7 + ... + A0)

This will give you linear adress space from $4020 to $7fff (and a second EPROM will handle $8000-$ffff as usual) and this can be done with a PAL/GAL chip easily. You could even probably do the logic to use all $4018 to $7fff.

While I fully agree it makes sense, form a software viewpoint, to avoid bankswitching completely, in hardware it takes less chips (or cheaper/simpler chips) to bankswitch the ROM at $8000-$ffff, which is why that's the way Nintendo did it.
Useless, lumbering half-wits don't scare us.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

The extra ROM would be basically the address decoder, and used in place of PAL/GAL chip, with an advantage to not require extra programmer device.

Not really follow the 46K with 74238/9 idea, though. lidnariq, could you please explain it? Seems to be a good trade, small chunk of memory vs. PCB size.

Edit: E1 and E2 to A15,A14 and A0-A2 to A11-A13, with one of outputs enabling the ROM, something like that?
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Post by lidnariq »

I'd designed something, posted it, and then realized it conflicted with the internal PPU and RAM — the design mapped the ROM into everything except $4000-$47ff. Oops. Fixing that is trivial, but involves another gate; if we're trying for a single IC solution it's lacking.

Let me try again, triple-checked this time, using a 74'85. Unfortunately, this only gets you 44kB ($5000-$ffff).

Code: Select all

     M2 -> A3
/PRGSEL -> B2 and ROM A15
    A14 -> A1
    A13 -> A0
    A12 -> A>Bin
ROM /CE <- A<Bout
vcc = B3, A2, B1
gnd = B0, A=Bin, A<Bin
Since the CPU's A15 is inverted for /PRGSEL, the top 32kB of address space would be on the bottom of the ROM and vice versa.

I'm not certain whether the '85 (add an 8 input OR) or '238 design is a better starting place if you're willing to add another IC to increase selecting memory by up to 4kB more. Either way, it sadly feels like diminishing returns.
80sFREAK
Posts: 275
Joined: Sat Sep 03, 2011 11:40 pm

Post by 80sFREAK »

Oh LOL! :lol: Do you really need that extra 2kB to start f**k around CPLD and PAL? 44kB not enough? This is the main reason of bank switching - good compromise between capacity and simplicity. Keep in mind, when Famicom/NES been released and cost of IC's at the time. Early 80' - 32kB memory were huge space.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

I think, goal of an extendend NROM design could be defined as '3 chips only with max amount of memory available'. Three chips are CHR and PRG ROMs + an extra chip, the latter is preferably cheap and compact one.

Since 40K would require decoding anyway, 44K is not too bad. Of course, more would be better, but it seems that the max is only possible to get with a CPLD or an extra ROM as decoder. I think, with all pros and cons the 7485 design wins over CPLD/ROM.
lidnariq
Posts: 11429
Joined: Sun Apr 13, 2008 11:12 am

Post by lidnariq »

I forgot that /PRGSEL can never* be 0 while M2 is 0, which allows us to get back to 46kB:

Code: Select all

     M2 -> A3
/PRGSEL -> B3 and ROM A15
    A14 -> A2
    A13 -> A1
    A12 -> A0
    A11 -> *A=Bin*
ROM /CE <- A<Bout
vcc = B2
gnd = B1, B0, *A>Bin*, A<Bin
It's more obvious what's happening now, too: A2..A0 compared to B2..B0 is "how does the number compare to 4?"

* Well, "never" as in it's transiently so at the end of a cycle that addressed $8000-$ffff. While M2=/ROMSEL=0, it'll act the same as though M2=/ROMSEL=1, so any glitching would only happen after reads from $c800-$ffff, should be fast enough to not propagate through the 74'85, and should be after the hold time for the CPU is over.

edit: misread the truth table, needed output to be inverted A11, corrections are *starred*
Last edited by lidnariq on Wed May 23, 2012 11:36 am, edited 1 time in total.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Post by Shiru »

46K with a single 74xx chip - that's neat. lidnariq, how do you think, could this be considered a reliable design? I'm not an EE, so I can't be sure (can only check logic tables, not edge cases with timings etc), but I would like to promote the idea of extended NROM into practical use eventually, and I like this design the best.
80sFREAK
Posts: 275
Joined: Sat Sep 03, 2011 11:40 pm

Post by 80sFREAK »

I will like this design after i will see working prototype
Post Reply