Mapper 16 Subset in Discreet Logic

Mapper 16 Subset in Discreet Logic
by qbradq on 2011-06-07 (#79402)

It's another week, do you know what that means boys and girls? That's right, it's time for another of QBRADQ's inane mapper discussions

This time I'm trying to create a super UOROM board again, but this time I have an eye to emulator compatibility as well. I have implemented some of the features of the Bandai mapper (iNES #16) in discrete logic, specifically 16-KB PRG-ROM banking, fixed bank, WRAM and 4-mode mirroring select (H, V, 1A, 1B).

I think I'll actually try to build this one into a dev cart. I've been itching to do a discrete logic project, and this seems like a good one.

Here is the project page which includes the combinational logic equations, theory of opperation, the schematic in PNG and Eschema formats and other KiCad support files. The archive also contains a preliminary DIY Layout Creator file for the perfboard prototype. I've only found this program today so I'm not quite sure how this will turn out.

I am looking for some advice on how to connect the mapper board to the NES. My first thought was to take an NROM board, desolder the components (other than the CIC), solder wires to the pins I need, then solder those into a 60-pin ribbon cable header. I would connect that to the mapper board via a 60-pin ribbon cable. That takes care of the cart connector, and I can reuse it latter for other boards.

What other approaches have you all seen to get prototype boards connected to the cartridge slot (other than a custom PCB)?

by tepples on 2011-06-07 (#79407)

Interesting idea. If we decide on a 60 pin ribbon cable, why not make the pins in the same order as on the Famicom cart connector?

Very interesting to implement the mirroring register with a decoder with latch (137) and a bus driver (125) instead of a latch (161/373) and a mux (153). What advantage does it have?

As the 6264 goes out of production, a 62256 with two address lines tied high might be the only replacement. It has no CS2, only an active low CS1. As I understand it, a 74x20 can decode this, replacing the 74x08. So can a 74x139, especially if you're worried about preventing spurious writes caused by M2-to-/PRG CE delay.

Might you need pull-ups on the output of the 373? Or are the outputs pulled up internally when in high-Z state?

by MottZilla on 2011-06-07 (#79410)

Your idea is probably what I would do, take NROM and remove all but the CIC and wire a connection to it. Doesn't matter what kind you use so long as its stable and works good for you. I hope this project succeeds for you.

by qbradq on 2011-06-08 (#79419)

Thanks for the input Tepples! I've learned something as always.

tepples wrote:
Interesting idea. If we decide on a 60 pin ribbon cable, why not make the pins in the same order as on the Famicom cart connector?

That's a great idea Tepples. I think I am going to go in a slightly different direction though. I've decided to cannibalize that Ultima Exodus cart I've been threatening for years. I'll leave the PRG-RAM and CHR-RAM in place on the cart and route the PRG-RAM enable signal from my mapper board. This reduces the amount of wiring I have to do by quite a bit, and I don't have to use any of my own RAMs.

tepples wrote:
Very interesting to implement the mirroring register with a decoder with latch (137) and a bus driver (125) instead of a latch (161/373) and a mux (153). What advantage does it have?

For one I didn't know what a mux was until I just read the 153 datasheet That's pretty handy. That's exactly what I need. Now if I didn't want to keep this thing compatible with mapper 16 I could use the high two bits of the latch I already have to drive it.

I am not entirely sure how to use a 161 as a latch. Could you explain?

tepples wrote:
As the 6264 goes out of production, a 62256 with two address lines tied high might be the only replacement.

Alliance Memory still produces 6264-compatible chips, and Mouser stocks them. But yea, it's a good call out. I don't expect these things to be manufactured forever.

tepples wrote:
Might you need pull-ups on the output of the 373? Or are the outputs pulled up internally when in high-Z state?

Yea, I've been nervous about this. In another thread kyuusaku suggests that the ROM address pins will float high when unconnected. However everything I can find online suggests that this is a very weak condition and is very susceptible to noise. I'll go ahead and add in those pull-up resistors. It's better than an OR gate in my opinion

by tepples on 2011-06-08 (#79426)

qbradq wrote:
I've decided to cannibalize that Ultima Exodus cart I've been threatening for years. I'll leave the PRG-RAM and CHR-RAM in place on the cart and route the PRG-RAM enable signal from my mapper board.

That sounds sort of like the Aladdin Deck Enhancer.

Quote:
I am not entirely sure how to use a 161 as a latch. Could you explain?

A 74x161 binary counter has an internal 4-bit latch.
While /Clear is low, 0 is copied to an internal latch.
When Clock rises while /Load is low, D0-D3 are copied to this latch.
When Clock rises while Count and CarryIn are high, the latch's value is increased by 1.
If the value in the latch is 1111 and CarryIn is high, CarryOut is high; otherwise it is low. This allows cascading multiple 161s to make a bigger counter. I seem to remember some pirate boards (or was it NES-EVENT?) using a bank of 161s for its IRQ timer.

CNROM, CPROM, GNROM, U*ROM, and A*ROM use this as a latch and never enable counting.

Take UOROM for example. D0-D3 of the 161 go to CPU data lines, and Q0-Q3 go through a 74x32 quad OR gate (value OR A14) to upper address lines of the ROM. I think R/W goes to /Load, and PRG /CE goes to Clock, or something like that; can someone confirm how these are wired?

by kyuusaku on 2011-06-08 (#79454)

Discreet? Hmm, I guess :P

In most designs registers are more appropriate than latches, the time to use latches is the rare case where their transparency will save you from replicating registers to meet timing requirements. (The '161 is a "latch" only in the data-holding metaphoric sense, it's implemented via a register because latches can't implement counters without multiple clock phases.)

I'd replace the '373 with a '374 (register). Doing that will also allow you to replace the OR and NOT gates with a '139 decoder. I would also connect D5 since there's no harm in supporting 8M ROMs, they're package compatible with 4M. Emulators probably implement the higher bits too even if the real deal doesn't have them.

I'm quite sure you really don't need the pull-ups, but put in a SIP bussed resistor network and try it out unpopulated at first.

The '137 and '125 is clever, but the '137 is rare, I've never even heard of it. I see it's obtainable, but I'd go with a regular register, such as the ultra common '74. I came up with this which will let you keep the '125 if you use a '74:

http://img810.imageshack.us/img810/5681/mux.gif

I think the '125 might be more elegant than a '153 if it turns out to be more available. Neither are extremely common, but the '125 has a smaller package, every gate is used and I think it might be cheaper on average.

Are you sure the mirroring bits are correct? It looks backwards to me so I have it wired like other mappers.

Oh lastly it would be a good idea to use one of the PRG register bits to enable/disable the WRAM by its CE2 unless you're going to put in a battery controller.

Lastly lastly, I assume you're opposed to working with PALs, but this design would be a perfect candidate. All the logic fits into a '374 and 16L8 with two functions to spare (they can implement decoded latches).

by qbradq on 2011-06-08 (#79465)

Thank you for your input! I have looked at using more traditional memory decoding logic, however this boolean approach just makes a lot more sense to me.

What I am trying to accomplish with this initial design is to get a working development cart, and then port my current project over to it as a proof of concept.

Obviously for replication a CPLD or similar would be in order. I am not terribly worried about that right now. For now I am just focusing on the bench model.

Now I'm trying to hack in a boot ROM and making the Flash ROM writable

How can you tell if a logic chip is "common"? And how exactly does that impact my project?

by qbradq on 2011-06-09 (#79496)

Huh, turns out mapper 16 / 159 is very poorly supported by emulators. Who would have thought a crap-ton of Dragon Ball Z RPG's would be a low priority for emulator writers

I've had some very good ideas with this project though. I may just do an MMC1 dev cart with a USB interface and a boot ROM. The only reason I picked mapper 16 was that it is easier to implement with logic ICs.

by Bregalad on 2011-06-09 (#79498)

qbradq wrote:
Huh, turns out mapper 16 / 159 is very poorly supported by emulators. Who would have thought a crap-ton of Dragon Ball Z RPG's would be a low priority for emulator writers

<tepples>
How many of them were translated in a popular western language ?
</tepples>

by qbradq on 2011-06-09 (#79501)

Zero

by Memblers on 2011-06-09 (#79505)

Just wanted to point out what you probably already know, that for Flash ROM writing, you will have to relocate the mapper registers. All the original mappers I've done put them at $5xxx. But if you must have emulator compatibility, it should be possible to put a mapper/flash select register somewhere, to select where writes to $8000+ are going.

CopyNES does that through one of the expansion port pins, that's how my UNROM Flash cart was writable (and I suppose the "PowerPak lite" also). But it's a bummer to not be able to have the NES program by itself able to write to it.

Quote:
How can you tell if a logic chip is "common"? And how exactly does that impact my project?

I use http://findchips.com/ and just make sure it's available at several major distributors. Good way to see the pricing and quantity in stock too. Of course, it only matters if you want to put it into production, if you're just making a few of them for fun then you can use whatever you want (in that case, I have some AX5202P MMC3 clones in DIP-40 package, if you're interested in wiring it up - but I don't think they're real suitable for a large production run).