NROM larger than 32K?
Moderator: Moderators
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.
'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.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
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.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?
...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? :)
'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.
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.
- infiniteneslives
- Posts: 2104
- Joined: Mon Apr 04, 2011 11:49 am
- Location: WhereverIparkIt, USA
- Contact:
You can run it on your system for a yearBananmos wrote: Maybe try building this cart and run it for a year's time to prove it's safe enough?
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.
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.
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.
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?
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?
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).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.
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
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.
Oh 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.
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.
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.
I forgot that /PRGSEL can never* be 0 while M2 is 0, which allows us to get back to 46kB:
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*
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
* 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.
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.