MMC3 on CPLD

I want to make the MMC3 mapper on CPLD (XC9572)
On the first step I tried to make the first part of CHR bank switching

Here what I did so far :
I used a nand to decode CPU R/W, /ROMSEL, CPU A14, CPU A13, CPU A0 to generate a clock signal right on the STA $8000
Then I used a 74HC161 to latch the command number
Then I used a 74HC138 to decode the command number
Based on the output of the 138 buffers latch PPU A10 / PPU A11 / PPU A12 to make available the needed block of VRAM

Decoding 8000 (100xxxxxxxxxxxx0) :
CPU R/W = 0
A15 = 1 , PHI2 = 1 --> /ROMSEL = 0
A14 = 0
A13 = 0
A0 = 0

Latching 8KB VRAM (PPU) :
2KB VRAM --> $8000 (XXXX X000)
PPU A10 = CHR A10
PPU A11 = 0
PPU A12 = 0

2KB VRAM -->$8000 (XXXX X001)
PPU A10 = CHR A10
PPU A11 = 1
PPU A12 = 0

1KB VRAM --> $8000 (XXXX X010)
PPU A10 = 0
PPU A11 = 0
PPU A12 = 1

1KB VRAM --> $8000 (XXXX X011)
PPU A10 = 1
PPU A11 = 0
PPU A12 = 1

1KB VRAM --> $8000 (XXXX X100)
PPU A10 = 0
PPU A11 = 1
PPU A12 = 1

1KB VRAM --> $8000 (XXXX X101)
PPU A10 = 1
PPU A11 = 1
PPU A12 = 1

Am I on the right direction?

The value you write to $8000 determines which actual bank register gets updated when you write to $8001, and those various bank registers are chosen based on the PPU address lines going into the PPU (whereas your schematic seems to show it using the value written to $8000).

This is a simple CHR Bank Switch :

LDA #$00 --> Command number
STA $8000 --> Selects 2 * 1KB VROM page at PPU 0000
LDA #$78 --> CHR bank number
STA $8001 --> Load 800h block of CHR (From 1E000 to 1E800) to PPU (From 0000 to 0800)

I don't know how to split and select VROM page (STA $8000), someone help me please.

First you'll want to implement the Namco 108 family (mapper 206 and friends) because it's simpler. Then you can add the extra MMC3 logic (mirroring switch, WRAM decoding, IRQ, etc.) once you have that working.

In any case, for N108 family functionality, you'll need a few dozen D flip-flops for eight bank numbers. $8000 bits 0-2 select which flip-flop to write to, controlling a decoder attached to the flip-flops' load inputs. $8001 writes to the selected flip-flop. Then you use muxes selected by PPU A12-A10 to select whether flip-flops associated with register 0, 1, 2, 3, 4, or 5 control CHR A15-A10 (or A17-A10 for MMC3).

Thanks for the info but I really need the answer for this :
How is the 8KB VRAM page of PPU selected?
Can I just hijack its high address lines (PPU A12, A11, A10) just similar to CHR-ROM?
I am talking about right at the STA $8000 for selecting the VRAM page
How does PPU know what address is going to fill in? 0000 or 1000 ... 2000

@ HardWareMan
This is awesome!
Did you test it?
How many macrocells does it need?

I did my own implementation. I'm using Altera and not Xilinx. But in general, the scheme is taken from someone's working draft of a project, maybe even PowerPack. You should remember this: MMC3 on this scheme contain 6 8-bit CHR registers (used only 7 bit of each register) and 2 6-bit PRG registers. Also it require about 15 registers for IRQ. Every single bit uses 1 CPLD's register.

The full blown MMC3 requires over 100 macrocells. Somewhere around 120 depending on the implementation.


I'm not sure if I understand your question, but the CHR-RAM and CHR-ROM implementation of the mmc3 is the same. The PPU has no idea what's going on with the MMC3. It just reads from the addresses it normally does when rendering and the MMC3 switches things around behind the scenes with respect to the PPU. The mmc3 is a slave to the CPU.

@ HardWareMan
Thank you

@ infiniteneslives
I am talking about the VRAM which is inside of the PPU, not CHR-RAM
Am I saying the wrong name?

That's what I figured. People typically call it VRAM on the famicom, but it's still ambiguous IMO. Although VRAM (aka CIRAM, aka NT/AT RAM) isn't inside the PPU, it's on the main board though. But you mention 8KB.. VRAM/CIRAM is 2KB. CHR-RAM is typically 8KB, that's why I thought you might have been asking about CHR-RAM.

I believe your question is actually to do with mirroring control. Although I still don't understand your question. There isn't really anything too special about the MMC3's method of mirroring control compared to other ASIC mappers with switchable mirroring. The mapper controls mirroring with the VRAM/CIRAM A10 pin.

Look that this (Page 16) :
Nintendo Entertainment System Documentation v1.0 by Patrick Diskin

It says :
The PPU has its own memory, known as VRAM (Video RAM). Like the CPU, the PPU can also address 64 KB of memory although it only has 16 KB of physical RAM ....

I said 8KB because I am referring to the pattern table area from $0000 ~ $1FFF
I want to know how can I split that area?

Sounds like you're mixing things up. That doc is okay for some light reading and gaining basic understanding of the NES.

Yes, true. Like I said though that RAM is on the main board, not inside the PPU.

FALSE, the PPU has no A14 nor A15. The PPU can only address 16KBYTE of memory.

Also FALSE. Well perhaps just bad notation. The NES has 2KB (BYTES) of VRAM/CIRAM which is 16Kb (bits). They improperly used big B instead of small b..

I recommend the wiki as a more solid reference.

And now you're talking about CHR-RAM on the cartridge which is used for Pattern Tables. You're not talking about VRAM/CIRAM on the NES main board which that doc is talking about. VRAM/CIRAM on the NES main board is used for Name and Attribute Tables. Cartridge CHR-RAM/ROM is used for Pattern Tables.

In any event you want to have 1KB bankswitching, so the mapper will have to control CHR A10 and up. That's the high level answer to your question.

@ infiniteneslives
Thank you for clarification
People says something about official docs!
Where are these official docs?
Can you introduce me some up to date and reliable source? (other than wiki)

The official Famicom docs are in Japanese, and the translations Nintendo provided to licensed developers were horrid. A lot of developers outside Japan ended up relying on reverse engineering to figure out how the PPU worked. (Source: posts by Andrew Davie, who worked on The Three Stooges, to the nesdev Yahoo! Group) Besides, I don't think anyone here has the legal right to distribute copies of the official docs to the public.

It really doesn't get more up to date than the wiki as it's the only living documentation as of today. Disch's docs and kevtris are your only real alternatives to the wiki when it comes to mapper info. The wiki is strongly based on Disch's docs though.

Having once been in your shoes I understand the frustrations of trying to understand the hardware when nearly all documentation is written from a software perspective (either NES programming or emu development). Kevtris is the only one that gives things from a hardware perspective. But his documentation requires a general understanding of the NES and mapper design to fully grasp.

If you stick with it long enough, once you understand the basics of mapper design all the docs start to make sense regardless of the perspective.

You have two separate problems.

The first problem is how to translate mapper port writes into changes to the mapper's state. For example, how to detect a write to $8000 or $8001 and how to handle it.

The second problem is how to do the mapping. The mapper needs to translate its state and the cart edge address into a ROM address using a bank of multiplexers (or "muxes" for short). The upper address lines (e.g. PPU A12-A10) feed into the select inputs of a bank of 8:1 multiplexers, one for each bit in the bank number, and the outputs go to the ROM. MMC3 has eight of them for CHR banks and six for PRG banks. There is one mux for CHR A10, one for CHR A11, one for CHR A12, ..., one for CHR A17, one for PRG A13, one for PRG A14, ..., and one for PRG A18. The mux for CHR A13, for example, has bit 3 of each of the six CHR bank registers as inputs.

Just the $8000 and $8001 logic requires 63 macrocells as flip-flops (5 for $8000, 7 each for regs 0 and 1, 8 each for regs 2-5, 6 each for regs 6-7) plus extra macrocells to act as the muxes and handle the write decoding. The most common simplification to fit into a smaller CPLD is dropping support for the largest ROMs, which saves a mux and 6 flip-flops per omitted CHR bank output or a mux and 2 flip-flops per omitted PRG bank output.

For posterity it's from artoh's FunkyFlashCart project:

viewtopic.php?f=9&t=463

@ kyuusaku
Thank you!

I found this too :



THE NES FUNKY FLASH CARTRIDGE

try?

No I didn't try it yet
TLROM needs 127 Macrocells.
Oh by the way PNROM is also available and needs only 57 Macrocells.

You completed yet?

I don't work on this project anymore
Because I couldn't find any suitable CPLD (5V + 44 pin + 128 Macrocells)

only xc9572xl now
72macrocells
44pin
output 3.3v
input 3.3 or 5v

Farid, the XC95144 chip they used on that cart are on eBay if you were still looking for some.

@ getafixx
Thank you
But it still has a lot of pins!
I am looking for something similar to the original MMC3 (44pin + 5V + 128Macrocells)
If anyone is aware of such a CPLD please let me know

or this img:http://savepic.net/6093678.jpg
Today, I try to make my own mmc3 cart,I found mmc3 not need 127Macrocells.
maybe 72Macrocells is enough.
I still have not completed
When I finished it can be determined how much macrocells need.

I'm pretty sure 72 isn't enough for full CHR bank bits and full scanline counter function. Regs $8000-$A001 take up 54 cells by themselves (46 for bank bits and 8 for reg values), the IRQ counter is 19 (counter + reload + various state), and there usually need to be a few more for logic.

I think you never find CPLD like this: (5V + 44 pin + 128 Macrocells). By the way if you find, you cannot made full implementation of MMC3, because CPLD needs programming interface and etc and you didn't have enough pins.

P.S. Sorry for my english.
P.S.S. And this is my full implementation FME-7 on XC9572:

Would you be willing to share the design files for that? Looks like you've got it split over 2 XC9572 chips?

Great job!
I found some fme-7 verilog code in fpganes.

Yes, I want to upload my verilog implementation to wiki, but I didn't make it because Ruslansh just take my sources and make a lot of carts for sale. Yes, I split implementation on 2 chips, because all CHR registers needs 64 macrocells and other 8 macro need for logic CHR banking.


Thank you. My implementation made from scratch. I've making this impl about six months, cause I don't have any experience in electronics, CPLD etc.

Plenty of copyright licenses intended for free software require redistributors to preserve an appropriate copyright notice on all copies. This might include labeling the board "MMC3 © 2014 nikita600". Or what were you expecting beyond credit where credit is due?

Given the way it's worded, I think he doesn't want money to be made out of it, at least without he getting anything from it.

I hope that nobody making money on my sources. That's all.


If I all understand right, I think you understand me

Ruslansh - pirate of 21th century)))))

If you are unwilling to license your design to manufacturers of homebrew games, then perhaps keeping it private is the best way to go forward.

I found a nice CPLD which can be fit inside of a regular Famicom Cartridge :



It has 320 Macrocells and it is 5V - PLCC 84pin (29.31x29.31)

EPM9320LC84 Datasheet

Price is about $110/ea for that chip in quantity of 75, though.

You don't necessarily need CPLD that's powered at 5V, just one that has 5V-tolerant inputs. Part families like Xilinx XC95XL and Lattice ispMACH are a couple examples (up to 288 and 512 macrocells, respectively). You just add a 3.3V regulator to power it. The NES and Famicom accepts 3.3V inputs just fine. So there are quite a few options, if you allow for 3.3V parts and QFP packages (PLCC is really big).

Though for a one-off build, it doesn't really matter, use whatever you want.

Come out with faster kazlina sources, an urgent need to make FC cart! Moron.

"please give me source code or I'll cry and call you a pooty head" Child, much? Just make your own implementation. You might even make a better version if you apply yourself!

Hmm, it's easy enough to put a copyright sticker on chips? Just something like ©IBM as an example of something that would fit even on a small one. "©αm." or "©αmule" if it was my copyright, as another example. That's the credit requirement equivalent for configuration firmware instead of sequential-state-machine (CPU/MCU/...) 'software'.

You do not know the whole essence of the confrontation. I know both of them, they know each other and, in general, very bad that they have brought their conflict to this forum at all.
Nikita600 is also not a saint too, spoiled the nerves of other good people, dumping their work on the public without permission.

I've made a lot of things about FC/NES/Dandy. Many of them used by various people. Some of them used this with profit. And Ruslansh always ask for my permission to use my work. I'm not a redneck, I always share if I was asked kindly.
Anyway, I think we should stop this offtopic in this thread.

If no chr(only chr-ram),xc9572 is enough.
I have finished this project.