N00B Needing Help with UQROM-4096 Board Design

[qbradq]

Edit: UQROM is just what I'm calling UxROM with PRG-RAM.

Hi all! As I have mentioned before I know just enough about hardware to be dangerous

I am trying to create a UxROM cart that can support battery-backed WRAM and 4MB of PRG-ROM. Realistically I would never have need of such a behemoth cart, but I figured it would be best to design it that way. When it comes time to build I would probably go with a 256KB board.

Anyhoo... after lots of reading on the wiki and the forums I've come up with this working design. It's basically the UxROM reference design with an 8-bit latch register and quad OR gates, plus the PRG-RAM reference circuit mashed together. I have also added an extra OR gate to prevent writes to WRAM from setting the bank select register, and I have added an PRG R/W inverter to prevent bus conflicts with PRG-ROM.

I am really just working on a whim and a prayer here. Can someone vet this design for me?

I might also want to add some sort of logic to swap between horizontal and vertical name table mirroring. I'll have to think about that though.

Also, I've got three 2-input OR gates not in use in this design. Any thoughts on how to make use of them?

Fairly large image

Thanks!

[kyuusaku]

CHR RAM is fine.

WRAM won't work. Instead of tying the NAND4 output to /WE, tie it to /CE, then GND /OE, and tie R//W to /WE.

As you have it the PRG ROM will only output on $C000-FFFF.. Assuming you are tying /CE to /ROMSEL, if not it won't work at all.

The '377 part won't work, I think you're using it like an active-low transparent latch instead of a positive-edge register with enable (latches and registers without enable are far more common thus preferable to a '377). It's because of the enable that the '377 has been used in NES applications though, connecting /E to R//W and CLK to "PRG /CE" means you don't need a decoded clock (same reason for Nintendo using the '161).

I would suggest using a '139 over a '20 to decode WRAM, they're one of the most common chips (top 5 easily) and can do the job about as well. Even better, if you add another '139 you can get rid of the '377 and use a more common '374. Using a '374 would also allow you to be tricky; if you tie the '374's /OE to PRG A14 you can do away with the OR gates because ROMs, even CMOS ROMs have TTL compatible inputs so they will float high automatically. That would reduce the mapper to 3 chips instead of 5. It can almost fit into two but you'd have to compromise the design.

Personally if I were going about this to get the board produced I'd go with a '374 and a legacy PAL, that way other features could be added like WRAM protection, the option to fix $8000-BFFF, one/two/four screen mirroring, shifting the register bits for CNROM/GNROM/AOROM compatibility etc.

[qbradq]

Wow, thanks for the tear-down

It will take me some time to wrap my head around this

[qbradq]

OK, so I've got the WRAM straightened out, and I like using the decoders to enable the PRG-ROM, but I've hit a snag. With the '374 there is no Clock Enable input. So how do I make sure it is only clocked on a write to PRG-ROM? I can't figure out how to make this happen without a hex inverter or something.

[kevtris]

I agree with the thoughts of using the 74139 for WRAM decoding. 74138's and 74139's can do much more than they appear on first glance.

Also, I had another idea just now. If you used something like a 74373 for the latch, you can use the 74373's tristate enable to perform the function of the OR gates. Just pull up all the outputs with say, 2.2K resistors (4.7K or 10K miight work) and then connect /OE to A14.

This way, when A14 is high it tristates the outputs forcing you to access the last bank of ROM. When A14 is low the outputs are enabled and you select the bank like usual. Saves a couple chips that way.

I suggest the 74HC logic family because it's fast and has decent drive and low power.

Also you can use the RAM's positive chip enable to help decode the addresses, too. MMC1 carts use it I'm pretty sure. Two chip enables are better than one in this case.

[tepples]

The 6264 has four enables: /WE, /OE, /CS1, and CS2. /OE we can't really use because we want to decode reads and writes the same way (I think). And the (more common nowadays) 62256 is missing CS2.

The formula to decode a read or write at $6000-$7FFF is
PRG RAM /CE = !(/ROMSEL & A14 & A13 & M2)

74139 according to the datasheet consists of two 2-to-4 line decoders with enable, which decodes 0-3 to driving one of the four outputs low and the others high and 4-7 to driving them all high. Call me dense, but I don't immediately see how this could be used to simulate the 4-input NAND of the 7420-based circuit, especially when also trying to get the feature of decoding PRG ROM without bus conflicts. Wouldn't we need to somehow decode a value of 7 into the /CS1? How is the 139 wired on mapper 86?

[qbradq]

Decoding WRAM with the '139 is pretty simple really. Each two-to-four decoder has it's own /E input. So you put PRG /CE and M2 into the first decoder so that output 3 is low when both are high. Then you loop output 3 back into the /E input for the second decoder. Then put A13 and A14 into the last two decoder inputs.

I think I may be barking up the wrong tree with this project though. I was thinking that the way emulators implement mapper 2 (I.E. allowing them to have battery-backed SRAM and up to 4MB of PRG-ROM) is by far the easiest way to develop NES software, assuming that you don't need fancy IRQs or software-selectable nametable mirroring, and you're using VRAM. The goal of this project was to create a cheap and easy-to-build cart that provides the full range of behavior that iNES mapper 2 provides.

The easy-to-build part I think I've got covered. The design is all through-hole components, and it's all discrete logic (so you don't need a JTAG programmer). The cheap part I can't figure out Getting PCB's manufactured, even in large-ish quantities, is very expensive! How does Bunnyboy offer his repro boards at $4? Just the PCB would cost me $10 to get made, and that's if I ordered a *lot*.

Anyhow, I had planned to provide the schematics and board layout under an open-source license, and the hope was that Bunnyboy (or some other place) would make a batch and offer them for sale. I have no plans of going into business

[tepples]

Decoding WRAM with the '139 is pretty simple really. Each two-to-four decoder has it's own /E input. So you put PRG /CE and M2 into the first decoder so that output 3 is low when both are high. Then you loop output 3 back into the /E input for the second decoder. Then put A13 and A14 into the last two decoder inputs.

So cascade both halves of the '139. Gotcha; thanks. I was just looking for some way to integrate bus conflict avoidance. If you've found some other way to invert R/W to produce /OE, that's even better.

Getting PCB's manufactured, even in large-ish quantities, is very expensive! How does Bunnyboy offer his repro boards at $4?

It depends on how many identical PCBs you can fit on each sheet of PCB material.

How big do 29F series flash chips get?

[qbradq]

So cascade both halves of the '139. Gotcha; thanks. I was just looking for some way to integrate bus conflict avoidance. If you've found some other way to invert R/W to produce /OE, that's even better.

The idea is ROM chip will be disabled when the RAM chip is enabled. I've taken care of that with another '139. I just can't figure out how to disable the latch register on reads.

It depends on how many identical PCBs you can fit on each sheet of PCB material.

How big do 29F series flash chips get?

It's a 44-pin Dip Do you think there is any chance that if I build and test a prototype that Bunnyboy would make a production run?

[kyuusaku]

Also, I had another idea just now. If you used something like a 74373 for the latch, you can use the 74373's tristate enable to perform the function of the OR gates. Just pull up all the outputs with say, 2.2K resistors (4.7K or 10K miight work) and then connect /OE to A14.

This way, when A14 is high it tristates the outputs forcing you to access the last bank of ROM. When A14 is low the outputs are enabled and you select the bank like usual. Saves a couple chips that way.

Using a '374 would also allow you to be tricky; if you tie the '374's /OE to PRG A14 you can do away with the OR gates because ROMs, even CMOS ROMs have TTL compatible inputs so they will float high automatically. That would reduce the mapper to 3 chips instead of 5. It can almost fit into two but you'd have to compromise the design.

One step and a few posts ahead of you, wow never thought this day would come haha


qbradq, there is no clock enable, but that's what the other '139 is for, you decode R//W and "PRG /CE" (/ROMSEL) to the clock pulse line. Data is sampled on the falling edge of "M2" (Phi2) which is also the rising edge of /ROMSEL (which is delayed but data is still valid). This is what I would do:

[Memblers]

What Flash chip is 44-pin DIP? Or is this EPROM? I've never seen larger than 512kB Flash in DIP, but I suppose there could be a TSOP on a carrier board/adapter.

PCBs are cheap to make. If you're paying $10 each, you must be getting a quote for a really small number of them. I pay about $100 to get a board setup and some prototypes sent to me. After that it's maybe $1.00 per board to produce more, it's entirely dependant on the board size. But the cost per square inch gets cheaper with larger quantity orders. So I guess with 100 boards, you would pay around $2.75 each (including shipping for proto/production separately, gold plating, beveled connectors and all that).

The price isn't all that bad for a much larger sized board. But you can make smaller boards with surface-mount parts, DIP parts are just huge. I fit a lot of stuff on this one:
http://www.parodius.com/~memblers/nes/s ... yellow.jpg
The first version was all through-hole parts, it's not a good layout but it's huge in comparison. Those supports in the NES cart case really get in the way.
http://www.parodius.com/~memblers/nes/s ... s/rev1.jpg

[qbradq]

qbradq, there is no clock enable, but that's what the other '139 is for, you decode R//W and "PRG /CE" (/ROMSEL) to the clock pulse line. Data is sampled on the falling edge of "M2" (Phi2) which is also the rising edge of /ROMSEL (which is delayed but data is still valid). This is what I would do:

I was thinking along those lines but I was not sure what the timming looked like. What would a WRAM protection circut look like? The cart does not have a reset line that I can find.

What Flash chip is 44-pin DIP? Or is this EPROM? I've never seen larger than 512kB Flash in DIP, but I suppose there could be a TSOP on a carrier board/adapter.

Futurlec carries an AMD 29F016 that is a 2MB flash ROM in a 44-pin DIP package. AMD also makes a 29F032 that is 4MB in the same package, but I don't know of a supplier.

But you can make smaller boards with surface-mount parts, DIP parts are just huge.

Very good point.

[kyuusaku]

I was thinking along those lines but I was not sure what the timming looked like. What would a WRAM protection circut look like? The cart does not have a reset line that I can find.

You'll have make something out of discrete components. If the goal is homebrew I would make a POR circuit clear the register, then use a register bit to enable the RAM. The safest way to prevent corruption should be to lock it between use. Otherwise I think I'd connect a comparator to VCC and a 4.5V reference then drive a tri-state buffer with the output. If the game has a robust save system protection really isn't necessary. I think most LP SRAM has some protection built in too.

BTW, I never thought of the spurious WRAM writes so I don't think my circuit is safe because /ROMSEL will propagate at around the same speed as the other decoder.

It might be safer to enable the WRAM through a chain of AND gates:

WRAM_CE2 = ((((A13 && A14) && PHI2) && VCC) && /ROMSEL)

Unfortunately it's very possible that the '139 inside the console decoding /ROMSEL is slower than the chain, both because of its manufacturing process and because its greater gate depth. I would suggest using the final 2:4 decoder to delay the first decoder further. If 74LS139 chips are used there's a good chance the glitch will be filtered.

I'm now trying to think of a suitable way to do it for any logic family (something synthesizable) without an RC delay or state machine.

[qbradq]

Wow, I'm really in over my head Thank you for working on this Kyuusaku!

[Memblers]

I'm doing a design for someone (not an NES cart), but the chip being used for battery backup is BA6162. It's an older part, but it would work good if it was available. It provides a positive chip enable, so you probably still will need an inverter (unless you go with 8kB)