It is currently Sun Aug 19, 2018 12:25 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 191 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 13  Next
Author Message
 Post subject:
PostPosted: Tue May 22, 2012 12:02 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 12:12 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2082
Location: WhereverIparkIt, USA
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... :)


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 12:44 pm 
Offline

Joined: Wed Mar 09, 2005 9:08 am
Posts: 410
Quote:
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? :)


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 12:58 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7471
Location: Chexbres, VD, Switzerland
'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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 12:59 pm 
Offline
User avatar

Joined: Mon Apr 04, 2011 11:49 am
Posts: 2082
Location: WhereverIparkIt, USA
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 1:01 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 1:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7393
Location: Seattle
Or, although it's nowhere near as much fun, you could use a 74'238 or 74'239 to get a 46kB aperture.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 1:37 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7471
Location: Chexbres, VD, Switzerland
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.

_________________
Life is complex: it has both real and imaginary components.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 1:44 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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?


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 4:22 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7393
Location: Seattle
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:
     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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 4:34 pm 
Offline

Joined: Sat Sep 03, 2011 11:40 pm
Posts: 275
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.


Top
 Profile  
 
 Post subject:
PostPosted: Tue May 22, 2012 4:35 pm 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 23, 2012 12:18 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7393
Location: Seattle
I forgot that /PRGSEL can never* be 0 while M2 is 0, which allows us to get back to 46kB:
Code:
     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.

Top
 Profile  
 
 Post subject:
PostPosted: Wed May 23, 2012 1:55 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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.


Top
 Profile  
 
 Post subject:
PostPosted: Wed May 23, 2012 3:42 am 
Offline

Joined: Sat Sep 03, 2011 11:40 pm
Posts: 275
I will like this design after i will see working prototype


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 191 posts ]  Go to page Previous  1, 2, 3, 4, 5 ... 13  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group