I've been wondering about this for a while. This may be a dumb question to some of you, but it's an interesting subject. Is it possible to make your own mappers with their own capabilities? If so, how come more homebrew mappers haven't been made? Or have they been? Sorry, this question has never really been answered directly to me, and I'm just curious.
This seems like more of a hardware question than a NESdev question. It certainly is possible to make a custom mapper (Squeedo comes to mind -- I'm sure there are others), you'd just have to build the chip/board for it. I'd imagine the tools required for making it would be pretty pricey though, but who knows.
Anyway -- I'm glad there aren't many custom mappers. It's hard enough for emu developers to keep up with the pace of existing mappers -- if nes dev people started creating wave after wave of custom mappers, it'd be a royal pain. I'd say you're better off just sticking with mappers that already exist.
Hmm, I was thinking about Squeedo, but I don't know why I didn't think of it as a custom mapper. If I were to make a custom mapper, it'd be like MMC1, but with like 1024k of PRG allowed, or something like that. I was just thinking about it, because I am going to be developing FF7 NES sometime in the future, and I was just thinking "What if I ran out of space"? I'm using 512k PRG with MMC1, and I really wish I was allowed 1024k. If I could make my own mapper, that'd be just great. But I don't know C/C++ to make my own emu, and I wouldn't want to have to pester someone to update an emu just for my own mapper. Thanks though, I've been wondering that for a long time
.
EDIT: I was about to put this in the hardware section, then I thought it had to do more with the developement of the NES.
Celius wrote:
I'm using 512k PRG with MMC1, and I really wish I was allowed 1024k.
Well this gets into whether you're actually doing "nes dev" or "dev for nes emus". Only a handful of games use the MMC1 variant that allows 512k PRG (Dragon Warrior/Quest 4 is the only game that comes to mind). You might want to go with something a bit more common.
Quote:
If I could make my own mapper, that'd be just great.
See... I'd say the exact opposite. Especially if you're not going to bother with the actual hardware. If emu authors bent over backwards to support every half-assed mapper design hackers or nesdevers dreamed up, things would be a total mess. You're better off just sticking with what's already around.
Quote:
But I don't know C/C++ to make my own emu,
Developing a special emu just so you could develop a game that wouldn't normally run on the platform being emulated is far beyond ridiculous. If you knew enough C/C++ to make an emu and you were in this situation -- I'd hope you wouldn't bother making a special emu just so it'd be the only emu to support your illegitimate game -- you'd just make the game in C/C++ and avoid the mess altogether (not to mention you wouldn't have any of the technical limitations the NES imposes).
It's not like I'm not even thinking about the hardware aspect. I'd want to build a cart and stuff for this. I'm not planning on doing this actually, it was just like "Oh, it'd be cool if I made my own mapper that was useful."
Bregalad and I have talked about what mapper to use, and we thought that MMC1 with 512k PRG Battery packed would be the best. CHR-RAM is a must, there is a ton of text/map data, and there is NO way this could be not battery packed. There is also MMC3, FF3j's version of the mapper. But Bregalad didn't like the idea of MMC3, so we just decided MMC1. And he was telling me about being able to convert Zelda to a 512k PRG cart. As a matter of fact, I have DQ4, and I bought it for like $10, and I could buy it again for the same price. I'm fine with this, MMC1+Battery+512k PRG is not a problem.
If I made the mapper, I would make sure everything works on the hardware before I went to tell emu developers to make this. That might sound backwards, but I'd put a lot of effort, and careful planning into the overall structure of this mapper before trying to test it out. I actually don't know what I'd do for sure, actually. I'm not planning on doing this, it was just an idea, and I was just wondering if you could make your own mapper, that's all.
Building your own mapper with mmc1 like capabilities would not be easy. However expanding mmc1 to 1024KB would be pretty easy. You would just need to do the same trick as Dragon Warrior 3/4 used, and steal the upper 2 chr address lines (chr a15 and a16) and wire them to the prg instead (prg a18 and a19). This gives you 1MB prg and 32KB chr. Emulators already have to do the dw 3/4 change so I dont think they would have problems doing it for your game. Emulators with good plugin modules should be simple to update. Your code just has to be careful when swapping chr banks to leave the prg bits the same.
This is just a wiring change on the board. There is NO special mmc1 version that supports more memory. You can use the chip from any mmc1 board.
(edit: WRONG) A bigger problem would be actually making the board. A 1MB eprom/flash chip would not fit in any board and you would likely need to use 2x 512KB anyways.
Building a basic MMC1 like mapper which supports 1mb of PRG ROM would only require two chips, a 74LS273 octal DFF and 74LS32 quad OR gate (or AND gate if you want $8000 fixed) assuming you're using CHR RAM and don't need selectable mirroring. It would also be insanely easy to program because it'd act like a 1Mb UOROM game. If you need mirroring control, that can be added with another 74LS08 and 74LS32 and if you don't want bus conflicts you can add a 74LS02 (use additional NOR as inverter for mirroring control). If you simplify all the logic, you can probably drop a chip as well. If you need WRAM, that can be added with a 74LS138 making it even cheaper/simpler. If you reduced it to only a 74273, 7404 and OR/AND gates, you could probably get it down to 4 chips by getting an obscure octal AND and octal OR ICs.
Imagine this layout: a single register mapped to $8000-FFFF
D7 = toggle WRAM /WE
D6 = ver/hor mirroring
D5-0 = 16k bank select
for protection the WRAM /WE can be pulled up.
Lastly, even I could implement this in FCEU in about 5 minutes, I'm sure I'd have more trouble just compiling it.
Edit #654: I was even bored enough to design and test it :P The only thing it could use is a better way to disable WRAM writes, I just realized the pullup is useless if the 8th flipflop starts up as a 1. If there was a circuit to reset the register at startup, that would be ideal. You could also replace the 74138 with another 7408 and use the left over inverters from the 7404 to decode the WRAM.
http://img135.imageshack.us/img135/3209/mmc1workaround6nx.png
Being a Famicom-not-NES enthusiast, I enjoy "custom" (who's the judge of that?) mappers and say go for it as long as your game doesn't suck and is worth the custom board.
For more complex designs (up to about 10 kilogates), making your own mapper is a four-letter word:
CPLD.
Custom mappers or not, it really depends on what you're goint to do with your game.
If you plan to have most people want to play it emulated, I strongly reccomand stuck with a normal mapper, and use the trick that was already said above is possible for 1024kB PRG rom, and you could use a 27C80 chip, that can fit a normal MMC1 board (unless I'm totally stupid). It would have to be implemented in most emus, tough.
If you are rich enough to plan team up with memblers and distribute actual cartridge, you are nearly forced to build your own board with your own cart and own mapper. You'll neeed lockout defeat, too.
But I really don't recoomand this for FF7 NES unless you want to go to prison or something, because you'd make benefit from the work of Square. This is very different from the first solution, wich is just one of numerous fan games based on real games, and I don't think game devloppers mind unless you really reach amazing quality. And today, even an amazing quality NES game isn't considered as it, so I think it is not risked.
However, if you would really distribute your games as an unlicenced developper, you'll have to make your own mappers, and use 74 series chips to build up what you want. Use 74 series chips to simulate a mapper such as MMC1 and MMC3 is possible, but quite complicated, so you'll have to simplify the logic to stuck what you want. In most cases, it won't be worth using a CPLD, because it is more complicated and expensive.
If I were to produce carts, I would certainly use a CPLD to synthesize an existing mapper, or use one to make my own register heavy mapper. If you have a mapper as simple as a single MMC1 state, I don't see why it wouldn't be better to use a handful of 74 series totaling $2 on your own PCB than having to rework an original cart. Not relying on Nintendo parts will definately be a plus, perhaps even a necessity when producing something.
I don't believe the MMC1 CHR address line thing is all that great since a 1mb version has never been implemented before and would still need to be added to emulators. I think my 5 minute 74 series mapper is more elegant from both a hardware and software standpoint because of it's efficiency.
Also I don't believe one could comfortably fit a MMC1 made from 74 series into a cartridge. I may try that sometime though :)
kyuusaku wrote:
I don't see why it wouldn't be better to use a handful of 74 series totaling $2 on your own PCB than having to rework an original cart. Not relying on Nintendo parts will definately be a plus, perhaps even a necessity when producing something.
Custom boards don't work on frontloaders with the improved protection against -5V jamming. You'll need at least the lockout chip from a Nintendo PCB, and by then you might as well just slap your own PRG into the PCB.
From a hardware/software design point for your game, using the octal ff looks much better than mmc1. Both designs would need to be added to emulators and both are simple. However if you want to produce a small number of carts looks like there is a good mmc1 board you can use. Search the
board table for SNROM or SJROM which has 256k prg, 8k vram, and 8k wram + battery. Then get a
27C080 or similar and use the datasheet pinout to compare to
256KB prg pinout for the rewiring.
SJROM has actually CHRROM, and only 28-pin CHR chips can fit in it, wich differs it from SKROM, wich has both 32-pin slots, and from SAROM, wich has both 28-pin slots.
For some reason, rumors float arround that SJROM has CHRRAM, but this is wrong, SJROM is like SKROM but it support only small CHR sizes.
Looks like both board references I use, kevtris
mapper site and the
nesdevwiki say it has chrram. Kevins pict shows a chr rom chip so it looks like the text is just incorrect. So it looks like unless something else I wrote is wrong, SNROM is the way to go for building small numbers of boards.
Agreed, but that is only for very small numbers.
It someone would be doing some mass production of a game written for MMC1, I'd reccomand change all mapper-related routines to remove the serial port thing, and have a parallel port, that will spare a lot of additionnal logic.
Then, you'd hardwire all that can be hardwired, such as the banking mode that you'd want to be fixed in most cases, and maybe mirroring (?) but that depend on the game. Of course, you'd need no latch for CHR as long as you're using CHRRAM.
So what should be implemented would be :
- PRG ROM latch for high adress
- OR/AND gate to have a reliable hardwired bank. To simulate SUROM, notice that there is two hardwired banks and there would be 4 if you use the trick to have 1024kb said above. So just don't apply OR logic on highest lines to toally simulate a MMC1.
- NOR game to avoid bus conflicts (unsure)
- Lockout defeater or better, lockout emulator (not available yet, if you see what I mean...)
- RAM decoder (either some logic gates or a 74HC139)
- Battery and protection componnants that comes with it.
- Of course, the PRGROM chip, CHRRAM chip and SRAM chip.
Could we not create a mapper description format for new mappers? based on the features in existing mappers and other ideas.