Trying to get an idea on the question: which kind of a mapper is best for homebrew projects, when there are no special requirements on its features and it is only used to extend PRG and CHR?
MMC1 seems to be popular choice, but it is slow, and complex - requires to salvage the chip from original games, or use a programmable logic chip. So it seems to have more drawbacks than benefits.
UxROM, AxROM, BNROM all allow to extend PRG and use CHR RAM, which has its benefits - no need in complex hardware, only one ROM chip needs to be programmed. It limits CHR bankswitch freedom, though (not very important, I think), and I'm not really sure if replacing a ROM chip with a SRAM chip is more or less expensive.
Not sure if there a discrete logic mapper that allows to bankswitch both PRG and CHR. It is possible to make a cheap mapper that does that, I think, but existing mappers are generally better because they are supported everywhere.
Any thoughts?
MMC1 games are a few buck each for cart case+PCB+mapper, I'll just leave it there. It might be complex, but it's still cheap and easy to use.
I myself love MMC3 despite never using it, it just has so much to mess with. I've used MMC1 in a project and it was easy to get going and nice, but I don't like it a ton as it's too simple. I do like being able to have 32KB RAM though donors. I love CHR-RAM on a mapper. If it existed, I'd probably experiment with a UNROM setup with a extra C*ROM touch of switchable CHR-ROM. That way it's cheap to make with logic chips and flexible for animations and such.
So, my mappers of choice for games would probably go: MMC3,UNROM+32KB CHR-RAM, MMC1, UNROM, NROM. It all depends on the size of the project, the first named mappers being my preferred for big projects going to smaller games. For a spin off project that I'll only make one cart of, I'll go a nice MMC1+SRAM+CHR-RAM to keep it simple and expand it to my hearts desire.
I've become a big fan of AxROM.
Advantages:
- 32k pages means you have a lot of freedom laying out the data in each page.
- CHR-RAM makes it easy to store a reasonably large amount of graphics (you can even try compression techniques).
- CHR-RAM makes some amount of CHR animation possible (see: Battletoads).
- CHR-RAM makes some very interesting rendering techniques possible (see: Solstice).
- Very simple to build (just requires one 74161 IC).
- Only need to flash one EPROM, since the other is SRAM.
Disadvantages:
- Not great for DPCM, since you have to duplicate it across all pages used.
- Can't do large CHR swap animations.
- Doesn't have horizontal or vertical mirroring (but you can switch to BNROM maybe).
SRAM is only a little bit more expensive than an EPROM for CHR (less than $1.50/chip).
Mapper 11 (colordreams) and mapper 66 (GNROM) are examples of simple mappers that let you switch both PRG and CHR.
Mappers 70, 78, 89, 152, are also simple.
How hard is it to add WRAM to a simple mapper?
Dwedit wrote:
How hard is it to add WRAM to a simple mapper?
Based on the difference between mapper 0 for NROM and mapper 0 for Family BASIC, it's two extra chips (74HC20 + 6264) and a bypass cap.
Also consider the comparison tables in the wiki:
main and
infrequently-used discrete logic
Why not to make your own mapper, which meet needs of your project?
Obviosuly, because it would be not supported by existing tools, namely emulators.
I really like the BxROM, for reasons very similar to the ones rainwarrior gave for liking AxROM. BxROM gives you more PRG space than any other discrete mapper, and is incredibly simple to make (requiring only a 74161, just like AxROM). The reason I prefer BxROM over AxROM is because I don't think that the few advantages of 1-screen mirroring are worth the 256KB of PRG you have to sacrifice for it (plus, 1-screen mirroring causes horizontal scrolling glitches).
Swapping the whole 32KB makes it a bit harder to access data from different banks, but this is not such a big problem once you find the optimal ROM layout for your project.
CHR-RAM is very versatile, even if you can't modify as many tiles per frame as instantaneous bankswitching of CHR-ROM allows. CHR-RAM makes a lot of sense for homebrews I think, since it can easily mimic the CHR-ROM of NROM, which every newbie is used to, but allows renovation and neat effects in case you want to give it a try.
Shiru wrote:
Obviosuly, because it would be not supported by existing tools, namely emulators.
Speaking of that, did NROM-368 die? Should I bother carrying support for it forward?
And plus it's more expensive than donors with one fourth the features. MMC3 donor game with case/mapper/PCB/Mapper/WRAM: $4 for Tecmo Basketball. Simple MMC1 board only via retrousb, no case or lockout: $10.
retrousb's MMC1 board has been "temporarily unavailable" for ages, though he'd probably bring it back if someone wanted enough of them at once.
An MMC1 donor is cheaper, but you gotta deal with the karma police for destroying historical artifacts, and also you have to remove the existing chips which is a serious annoyance.
A repropak/case/lockout, chips and stuff for AxROM will run you about ~$20 per cart (more or less depending on how much you are doing). ~$25 for MMC1 (if it ever comes back) plus probably another $1.50 for WRAM if needed.
I'm not going to say I've never destroyed vintage hardware for my own purposes, but if I'm going to make 50 carts of something I will feel a lot easier about using new parts. I'm not going to complain about people who do it (they're your carts, wreck 'em if you want), but I'm saying personally I'd rather not.
My latest UNROM board does 4x 8KB CHR RAM banking, so animations are easier. Assimilate used it mostly for cut screens and big enemies. I have always liked the split/fixed banks UNROM uses so it is what I typically recommend.
bunnyboy wrote:
My latest UNROM board does 4x 8KB CHR RAM banking, so animations are easier.
Cool. This is great for background animations such as coins spinning, water, and other things that make levels look "alive" (4 frames should be enough for most things). Or for holding more animation frames of the main character (all other tiles are repeated across the 4 banks).
cpow wrote:
Speaking of that, did NROM-368 die? Should I bother carrying support for it forward?
Not yet. I plan to use it for a project, just need some time.
Shiru wrote:
Obviosuly, because it would be not supported by existing tools, namely emulators.
It's actually a good point if you want to sell cartriges. And with your own mapper you can do more features
If your mapper doesn't work in emulators or on a PowerPak, and you plan to use the fact that it doesn't work as copy protection, then how are you going to test the game to make sure it works before you sell it? I'm under the impression that using an EPROM programmer, a socketed board, and an NES modded to allow insertion of socketed boards is unbearably slow if you use it for every single build, and not every team has someone with the skill set to design a PCB.
I agree that a custom mapper is a good thing if you want copy protection. It slows down developement, but it is possible to mod an emulator for dev purposes, and keep it private.
tepples wrote:
If your mapper doesn't work in emulators or on a PowerPak, and you plan to use the fact that it doesn't work as copy protection,
It will slowdown pirating.
Quote:
then how are you going to test the game to make sure it works before you sell it?
On the real hardware
Quote:
I'm under the impression that using an EPROM programmer, a socketed board, and an NES modded to allow insertion of socketed boards is unbearably slow if you use it for every single build,
There is another route for those, who conmmon with hardware, but since
Quote:
and not every team has someone with the skill set to design a PCB.
i feel myself like last samurai. Just wonder, where is real hackers gone...
Shiru wrote:
I agree that a custom mapper is a good thing if you want copy protection. It slows down developement, but it is possible to mod an emulator for dev purposes, and keep it private.
Keep it simple - would you like to have VRC7 sound for your games? Would you like extra memory for saves? Would you like more flat memory for PRG code?
Ha ha, it will slow down pirating a teensy tiny bit. This community has reverse engineered every other mapper already; what's going to keep them from figuring out yours? (Anyone who can desolder a chip and use an EPROM programmer can dump the data, even if the mapper is unknown.)
Putting sound in your mapper is only good if you're targeting only Famicom, or modded NESes. Probably most homebrewers here are not aiming for either of those.
Tepples, my
socketed cart fits okay inside a front-loader; the real problem was fitting the chips in the cart (have to cut a window in the casing), but the cart fits just fine under the tray bar. No mod to the NES is necessary, but yes it is a really slow process; only really useful for final testing.
rainwarrior wrote:
Ha ha, it will slow down pirating a teensy tiny bit. This community has reverse engineered every other mapper already; what's going to keep them from figuring out yours? (Anyone who can desolder a chip and use an EPROM programmer can dump the data, even if the mapper is unknown.)
there is couple tricks, which can surprize you
Quote:
Putting sound in your mapper is only good if you're targeting only Famicom, or modded NESes. Probably most homebrewers here are not aiming for either of those.
sorry, always forgetting, that NES is castrato.
Quote:
Tepples, my
socketed cart fits okay inside a front-loader; the real problem was fitting the chips in the cart (have to cut a window in the casing), but the cart fits just fine under the tray bar. No mod to the NES is necessary, but yes it is a really slow process; only really useful for final testing.
Good man, but who said to use standart equipment for prototyping?
2 Shiru there is two ways when existence drive your consciousness or opposite.
There are a lot of things you could do to slow down piracy. I don't think there's really anything you can do to stop it entirely. Really, the thing that will determine whether your game is pirated is whether it's any good, and how many people get their hands on it. If it's worthwhile enough, somebody will crack it. Some people will want to crack it just for the challenge.
To me, it doesn't really seem worth the extra development time spent customizing emulators, time spent ensuring reliability, etc. but if it's important to you go ahead and try.
Put the ROM with all data compressed in some weird way and then just screwed up and have a boot loader read it, decode it, and then shove it to a huge PRG-RAM inside the 8000-FFFF space?
Really, we need to do what Pier Solar did and just make a mapper that no emu author will emulate. And make it expensive to do in hardware but easily hardware detectable. And then the best way to trigger it would be code your entire game engine like earthbound where it will only make it ridiculously hard and not fun if they pirate it, but yet not so obvious in the program/RAM map to the point where you have to NOP out one piece of code.
3gengames wrote:
Put the ROM with all data compressed in some weird way and then just screwed up and have a boot loader read it, decode it, and then shove it to a huge PRG-RAM inside the 8000-FFFF space?
LOL no.
Quote:
Really, we need to do what Pier Solar did and just make a mapper that no emu author will emulate. And make it expensive to do in hardware but easily hardware detectable. And then the best way to trigger it would be code your entire game engine like earthbound where it will only make it ridiculously hard and not fun if they pirate it, but yet not so obvious in the program/RAM map to the point where you have to NOP out one piece of code.
Nice story, you should become a writer
All this cries sounds like "Oh, i can not play this new game on my emulator". LOL
Just think about it - what was first game or mapper for that game?
80sFREAK wrote:
3gengames wrote:
Put the ROM with all data compressed in some weird way and then just screwed up and have a boot loader read it, decode it, and then shove it to a huge PRG-RAM inside the 8000-FFFF space?
LOL no.
Quote:
Really, we need to do what Pier Solar did and just make a mapper that no emu author will emulate. And make it expensive to do in hardware but easily hardware detectable. And then the best way to trigger it would be code your entire game engine like earthbound where it will only make it ridiculously hard and not fun if they pirate it, but yet not so obvious in the program/RAM map to the point where you have to NOP out one piece of code.
Nice story, you should become a writer
You act as if your solution (Which you forgot to post I hope) is better than either of those. I'd like to see you create a better solution. I've thrown around many ideas for piracy protection for my own software, you think I'm not 100% serious about what I posted? Why would you even reply to me mocking my ideas and not even giving a reason why they're bad ideas? Prick move, that's all I'm saying.
ETA: The mapper doesn't matter, you want semi-serious copy protection you'll have to do something yourself with your own hardware/software mix. And you should be able to develop on emulator and then add the protection when testing on a real hardware by changing one file from blank to the code needed, then use it as just a JSR function.
3gengames wrote:
You act as if your solution (Which you forgot to post I hope) is better than either of those. I'd like to see you create a better solution. I've thrown around many ideas for piracy protection for my own software, you think I'm not 100% serious about what I posted? Why would you even reply to me mocking my ideas and not even giving a reason why they're bad ideas? Prick move, that's all I'm saying.
I didn't said your ideas bad, just there is another way to do to make surprize
Quote:
be able to develop on emulator
Quote:
emulator
This. You always talking about emulator. Why? Ah, i see
Quote:
just a JSR function
Oh, well.
Aside from putting the content of your game online, on a secure server, is there any successful commercial game with an anti-piracy device that has not been cracked?
The description of any anti-piracy technique is ultimately a description of how to crack it as well. Nothing is safe. Even things like suicide switches that destroy the game if you open the cart or read certain addresses can be circumvented. Many techniques are error prone and probably lead to a lot more legitimate user frustration (e.g. blinkies) than prevented piracies.
3gengames wrote:
Put the ROM with all data compressed in some weird way and then just screwed up and have a boot loader read it, decode it, and then shove it to a huge PRG-RAM inside the 8000-FFFF space?
Wouldn't a pirate just get the data after it was decoded to $8000-$FFFF?
3gengames wrote:
then use it as just a JSR function.
If your copy protection is just a function that you JSR to, that should be pretty easy to hack, no?
80sFREAK wrote:
I didn't said your ideas bad, just there is another way to do to make surprize
Then fucking say what's on your mind already, instead of "teasing" everyone with your shitty one-line responses. Seriously 80sFREAK, your participation in this forum is quite annoying. You only show up to say that everyone's ideas are crap, but you hardly ever explain why or say what would be a better way to do things. If you have better ideas in mind, just share them right away or shut up. Nobody thinks you are clever just because you're keeping information from us.
Quote:
You always talking about emulator. Why?
Because we use emulators for developing? Developing exclusively on hardware would be a very tedious task, and even if we could absurdly speed up the time it takes to transfer a new binary to the NES, we still wouldn't have all of the debug features offered by emulators.
tokumaru wrote:
Developing exclusively on hardware would be a very tedious task, and even if we could absurdly speed up the time it takes to transfer a new binary to the NES
Which an "EPROM emulator" does.
Quote:
we still wouldn't have all of the debug features offered by emulators.
Unless you're of the mindset that debugging should be done with test-driven development methodology. (Yeah, that was weak.)
There are plenty of ways to make life harder for pirates:
- Put a coprocessor of sorts in the mapper, which handles things like multiplication, crypto, and decompression
- Store most of the game on a big eMMC or microSD soldered onto the cart PCB and copy part of the game to PRG RAM at once, like a big PowerPak or the FDS or like the old CD consoles
Yeah, but how are you going to detect it when you don't know when it's called or what variable it flips? Plus, not just one function, you can use multiple functions that look different but work the same and are in different locations.
And I guess they could, but you could still check for special hardware or something the decoding does, like put something in RAM and also run a checksum routine at times. I'll reply better later and once I think it more through.
3gengames wrote:
And I guess they could, but you could still check for special hardware or something the decoding does, like put something in RAM and also run a checksum routine at times. I'll reply better later and once I think it more through.
Someone said it here already, but there will *always* be at least one person in the world with enough determination, interest, and plain-old hacker curiosity to take whatever you create and spare no expense to figure it out. Until machines that we create start creating things that we didn't originally intend for them to create [when we hit the Kurzweil'ian "singularity" in a few years!], no human will ever be able to completely outsmart other humans with a machine he/she has created. Especially when said humans can pretty much
do anything.
tokumaru wrote:
80sFREAK wrote:
I didn't said your ideas bad, just there is another way to do to make surprize
Then fucking say what's on your mind already, instead of "teasing" everyone with your shitty one-line responses. Seriously 80sFREAK, your participation in this forum is quite annoying. You only show up to say that everyone's ideas are crap, but you hardly ever explain why or say what would be a better way to do things. If you have better ideas in mind, just share them right away or shut up. Nobody thinks you are clever just because you're keeping information from us.
Quote:
You always talking about emulator. Why?
Because we use emulators for developing? Developing exclusively on hardware would be a very tedious task, and even if we could absurdly speed up the time it takes to transfer a new binary to the NES, we still wouldn't have all of the debug features offered by emulators.
Too much bad words from you to share any information. Keep emulating, i stay by hardware side
2 3gengames you just gave me one interesting idea and i will check it on hardware
2 cpow right, and protection have to be just good enough to knock down 95% of greedy kids
I don't need you to share anything, bro, I just want you to stop the bullshit. If you have something useful to say, say it, otherwise shut up. You look like a dick when you act like you're superior to everyone else.
tokumaru wrote:
I don't need you to share anything, bro, I just want you to stop the bullshit. If you have something useful to say, say it, otherwise shut up. You look like a dick when you act like you're superior to everyone else.
I think 80sFREAK is having a problem with the "fucking", "bullshit", and "dick".
Seriously?
Why do you need copy protection?
What are any of you worried about? The NES is 20+ years old.
tepples wrote:
I think 80sFREAK is having a problem with the "fucking", "bullshit", and "dick".
RONALD MCGODDAMN DONALD! This Reminds me of Tourettes Guy:
http://www.youtube.com/watch?v=5wcKpoAQKj4
Obscurity is the best copy protection. If nobody wants it, nobody pirates it.
tokumaru wrote:
I don't need you to share anything, bro, I just want you to stop the bullshit. If you have something useful to say, say it, otherwise shut up. You look like a dick when you act like you're superior to everyone else.
Why so much butthurt?
2 tepples not really, but threads like this showing who is who - "gimmi it now or shut up" with few variations.
2 Drag as for me it is not about copy protection, which is side effect against emulators, but more features, mainly sound extensions.
80sFREAK wrote:
2 Drag as for me it is not about copy protection, which is side effect against emulators, but more features, mainly sound extensions.
In that case, how much time will be spent serving IRQs so that generated samples can be copied from the mapper to the APU?
tepples wrote:
80sFREAK wrote:
In that case, how much time will be spent serving IRQs so that generated samples can be copied from the mapper to the APU?
Samples? Copied? what for?
Unlike the cartridge connector of the Famicom, the cartridge connector of the NES has no dedicated audio pins. There are audio pins on the expansion port and general-purpose pins on the cartridge connector that go straight to the expansion port. In theory, an NES game could come with a jumper pack that fits in the expansion port and connects the general-purpose pins to the audio pins. But no NES game ever came with such a jumper pack, and the NES-101 has no expansion port anyway. This means the DMC and timed writes to the DAC at $4011 are the only way to play audio synthesized by the mapper on an unmodified NES.
Of the following possibilities, which were you planning to use?
- Have such a jumper pack manufactured, include it with each copy of the game, give detailed installation instructions in the manual (including how to pry off the plastic cover that ordinarily covers the expansion port), and warn on the box that the game's audio will be incorrect on the NES-101.
- Have your mapper calculate audio samples and make samples available for the CPU to read from the mapper and then write to $4011. This is the "copied" to which I was referring.
- Have your mapper compress synthesized audio to DPCM in real time and then play it back on the DMC with a 1-byte loop.
- Include a 3.5mm miniplug jack directly on the cartridge, play all audio through the cartridge, and warn on the box that external speakers will be required for use with NES-101 or other RF setups.
Another good way to discourage piracy is to make your game priced affordable and make it easy to purchase. People generally don't pirate games that they can easily buy for cheap. But you bet they'll pirate games that cost a small fortune.
As far as copy protection with hardware, definitely you'd need to design your game to *rely* on your unique hardware. That means you'd need to get away from simple bankswitching setups. As suggested have some sort of processing assistance or just other quirky things you could work into it. If it then costs more to bootleg than to buy it, they'll probably just buy it.
You should also figure that the audience for new NES/Famicom games is different than in a general sense. Perhaps anyone interested in a new game is more inclined not to pirate it? Or maybe not.
tepples wrote:
Unlike the cartridge connector of the Famicom, the cartridge connector of the NES has no dedicated audio pins. There are audio pins on the expansion port and general-purpose pins on the cartridge connector that go straight to the expansion port. In theory, an NES game could come with a jumper pack that fits in the expansion port and connects the general-purpose pins to the audio pins. But no NES game ever came with such a jumper pack, and the NES-101 has no expansion port anyway. This means the DMC and timed writes to the DAC at $4011 are the only way to play audio synthesized by the mapper on an unmodified NES.
Of the following possibilities, which were you planning to use?
- Have such a jumper pack manufactured, include it with each copy of the game, give detailed installation instructions in the manual (including how to pry off the plastic cover that ordinarily covers the expansion port), and warn on the box that the game's audio will be incorrect on the NES-101.
- Have your mapper calculate audio samples and make samples available for the CPU to read from the mapper and then write to $4011. This is the "copied" to which I was referring.
- Have your mapper compress synthesized audio to DPCM in real time and then play it back on the DMC with a 1-byte loop.
- Include a 3.5mm miniplug jack directly on the cartridge, play all audio through the cartridge, and warn on the box that external speakers will be required for use with NES-101 or other RF setups.
Ah, NES... Enjoy the silence
MottZilla wrote:
Another good way to discourage piracy is to make your game priced affordable and make it easy to purchase. People generally don't pirate games that they can easily buy for cheap. But you bet they'll pirate games that cost a small fortune.
Absolutely. Mass-production(say chinese) pirates prefer well known titles and time to time changing CHR content. Homebrew pirates(say repro makers) most likely will not do that, if cost of repro(or dealing with custom parts) is above original cart cost.
Quote:
As far as copy protection with hardware, definitely you'd need to design your game to *rely* on your unique hardware. That means you'd need to get away from simple bankswitching setups. As suggested have some sort of processing assistance or just other quirky things you could work into it. If it then costs more to bootleg than to buy it, they'll probably just buy it.
Not only for that - tricky bank switching might fit your needs better to compare with standart mapper - Konami VRC7 and SunSoft 5B are good example.
Quote:
You should also figure that the audience for new NES/Famicom games is different than in a general sense. Perhaps anyone interested in a new game is more inclined not to pirate it? Or maybe not.
I think is most likely yes(with small exceptions) plus keep in mind donations
Wait, do we have a problem with people pirating homebrew NES carts? (Really?)
I thought you were referring to pirating just the ROM. There is no parts cost for distributing a modded emulator and ROM image.
rainwarrior wrote:
Wait, do we have a problem with people pirating homebrew NES carts? (Really?)
According to this post it seems so.
I meant people building pirate carts.
I expect people to pirate the ROMs.
I don't mind paying but I do want a computer file .NES without copy protection and so on.
I know I'm a little slow to chip in, but I finally got Internet access back again and had to chime in.
I agree that if someone really wants to crack your copy protection they will. But for home brews I can see how the author would want to discourage the act. In reality most of the people with the NES specific knowledge are already on this board and I think we as a community wouldn't share a hack to pirate another member's work. So really all you have to do to stop the simple cart hacker is do something simple. Merely making something not work on a standard NES pcb or in an emu would be enough to stop most novice repro makers.
If they learned enough to hack it well good for them. But I think it'd be pretty easy to stop most people based on the repetive questions that come up on how to produce carts that are super simple. I'd like to think the people in the community here would could figure out would respect the author and not publicly share the hack or add emu support. And as far as developing a game with said mapper you could easily create the game with any mapper and then slightly modify it once complete to work on the modified mapper, even if it were some simple register swapping or something.