Which discrete mapper has both CHR and PRG RAM?

Originally I was going to look into beginning UxROM development but the I realized from looking at the wiki that it doesn't have PRG RAM. I checked the other mappers and couldn't find the combination of both CHR RAM and PRG RAM I was looking for, in a discrete mapper like NROM - I don't get why that seems to support PRG RAM and not the bankswitched discrete mappers.

So I was wondering if anyone knew of a discrete mapper supported by ReproPak that has both CHR and PRG RAM.

I say discrete so it could be manufactured by hand.

Sorry if this post is retarded - I'm more of a software guy.

Family Basic carts had PRG-RAM. The wiki lists out most of the options you've got for a discrete mapper anyways.

Although you'd have to hack a repro-pak quite a bit to get that circuit and prg-ram on there...

One possible option is to use battery backed SRAM as PRG-ROM. You'd have to sacrafice some rom space for ram use, and be sure not to ever write to rom space. If 32KB of combined PRG-ROM and RAM was enough then you could do it. But for a game small enough to fit on NROM, I'd argue 2KB is enough RAM especially if you have CHR-RAM as well.

More or less any mapper that doesn't explicitly have control registers from $6000-$7FFF can have RAM superimposed on it. But I don't think you'll be able to buy a ready-made kit that makes the mechanical assembly not a pain.

Just curious: what do you need the PRG-RAM for? Are you sure you can't make it work with only 2KB of RAM?

Basically primarily to have an easier time of programming. Decompress a large horizontally scrolling map (8-screen wide maximum) in one go and use 16-bit coordinates for objects. It will have lots of advantages besides just making things easier to code though like objects being able to navigate and interact with the map + any changes the player has made to it without having to be onscreen.

If it isn't destructible, honestly sounds like a huge waste. You'll still have to decompress it. Might as well make it stage-based.

Well that's the point, I want to be able to see how I can maximize a large decompressed map and do beyond what 2K permits. BTW the game idea is a top-down open world adventure with a focus on lush complex scenery (see my post in Homebrew with WIP screenshots).

Not to mention it will be easier and quicker to code. I'm using a lot of proprietary bytecode to code the game much more rapidly than doing it all in plain 6502 would be. Therefore it will be better to decompress each map while PPU is off rather than trying to make it work as you scroll. It will just be too slow to keep a smooth framerate.

Kinda surprised the focus is on "waste" rather than advantages. Besides I'd only be using 12x16x8 of it (1536) I would like to have as much RAM as possible for other uses. Like decompression buffers for other data, like tables. Self-modifying code. You could say just as easily that the address space $6000-$7fff would be wasted without the RAM!

In any case, I think you shouldn't worry about the hardware yet (beyond some minimal "is this feasible?"). Making hardware is really a nice capstone to make a project Real, but its difficulty and complexity is notably less* than writing a game.

Also, remember that using NES 2.0 headers will let you get PRG-RAM with at least Nestopia and Nintendulator.

* Exception: If you want the entirety of MMC5 or Namco's 163.

That's where I'm at. I just want a mapper config that will work with emulators, ReproPak, and is feasible with custom hardware. I am not actually going to build any carts myself though. mham hopefully will help out with that.

I will look into changing my header to NES 2.0. That sounds promising. Thanks!

Sounds like a good fit for something like MMC1 or MMC3. If you really don't have much intent on building carts yourself there isn't much benefit to discrete mapper's limitations especially if you're really looking for PRG-RAM. Don't expect emulators to provide PRG-RAM support on discrete mappers. Designing your game for one of these mappers will give you the most flexibility and achieve your goals.

You can always use a compressing algorithm that allow pseudo-random access. For example, have an index at the start of every row or every column. So that you'll never need to have more than one row or column of the map in memory. Of course it'll be slower but you can't have them all.

The US version of Maniac Mansion, for example, was hacked from UNROM to MMC1 so that it could run on an official board with battery RAM (SNROM). But MMC1 has a much bigger switch penalty than, say, UNROM, and bank switching in the NMI handler is more problematic because it's not atomic.


It worked for Family BASIC, and the NES 2.0 spec appears to require it. However, "don't expect any old random emulator to support NES 2.0" is a valid concern.

Another thing you could do is to make up a mapper something like what I did here; therefore it can work with a ASIC mapper while also being easy to build a discrete mapper with the subset of features you are using.

wow thanks man. i think this looks like exactly what i was looking for. no fancy mapper features just the extra legroom!

edit: oops, spoke too soon, didn't realize there was no CHR RAM in that config. and i have no idea if on top of that config for example i can feasibly have CHR RAM too. is it just a matter of selecting it in the header (and presumably using a RAM chip in place of ROM)? is NES 2.0 required for this?

Despite what everyone else said, iNES (unfortunately) implied 8KiB of PRG RAM for almost all mappers, in the standard place. I think no extra work is needed from you, although adding error detection ("do I have RAM?") and a message would be clever. NES 2.0 headers have the advantage that they make what you want exactly clear, rather than relying on heuristics. (And, they're backwards compatible, so the only badness to including NES 2.0 headers is "someone won't understand and treat it as though they don't exist")

There's no need to use precisely zzo38's MMC5 subset; you could start with any other ASIC and pick some trivial subset. (Obvious choices for "UNROM banking, PRG RAM, CHR RAM" are VRC3 (m73) and BA-JUMP2 (m153))

Also, 8KiB CHR-RAM is a trivial exchange for 8 KiB CHR-ROM in all contexts.

Thanks for the edification.

I found this cool wizard that helped give me some more confidence. http://pineight.com/nes/mapperwizard.html

Looks like what I'm going to be developing for is most likely SNROM. That has bankswitched PRG, 8kb PRG RAM and 8kb CHR RAM.

Glad I could be helpful.

you made this? it's really nifty! i was wishing for something like this, was kind of surprised when it popped up in my google search.

edit: the only thing is i couldn't find a repro board on RetroZone that supports SNROM. I guess ReproPak supports it though, which is fine for development just not production.

edit 2: also looks like it is an MMC1 config which would require more than just some wired-up chips correct? from my understanding MMC1 mapper chips are not something you can just buy in bulk...

Whether you use SNROM for maximal emulator compatibility is almost entirely separate from the hardware you should use when you actually assemble the PCB.

Use good abstraction principles so that you can assemble two versions of the same game, one using MMC1 and one using UNROM.

Or, really, just use a NES 2.0 header specifying UNROM or NROM with PRG-RAM and CHR-RAM. Emulators ignorant of NES 2.0 will usually give that to you anyway.

If you don't want the more sophisticated features, don't worry about it yet. It's always easy to spec up; it's much harder to spec down.

I'll note that with Driar, the original was released as "unknown MMC1", assumed to be SNROM. I looked more closely, converted it to SGROM, then converted it to UNROM, and after I was allowed access to the source code, converted it to NROM.

I love how the mapper wizard tells you how you have to destroy particular games to get stuff done

Hopefully after the prepopulated version of INL-ROM comes out, there won't need to be so much destroying of uncommon donors, and I'll be able to revise my advice.

That actually made me kinda sad when I saw it awhile back. But it sparked the discussion to create these:

I gave a nice hefty update on my INL-ROM v1 boards. Many of those mappers/board conigs are now released. I'm still working on some of those odd-ball ones like TQROM and such. One other thing that could probably be added to the wizard is options for >8KB of CHR-RAM. 32KB is basically free, and iNES 2.0 supports it as well. I'd argue that finely bankswitchable CHR-RAM is the most powerful, versatile, and cheapest option if you're hoping to put your homebrew on hardware. I initially named them "hombrew TNROM", but something like "super TNROM" or "super SNROM" sounds a little better. Perhaps a more technical/explicit name would be better though. Not much point for something like TQROM for a homebrew IMO.

Heh, I'm the exact opposite. I find it really fun to think of clever ways to accomplish things on simpler hardware. OTOH, I'm not exactly known for finishing my projects!


Horizontal maps can be easily decompressed on the fly. If you mark some spots in the stream you can even scroll backwards without much trouble.


That's something you should do regardless of how you decompress the map. Even if you don't have access to the whole map at all times, object coordinates should be relative to the complete map.


Unless you plan to modify several hundreds of blocks in a single level, there are alternative ways to keep track of level map changes that don't require lots of RAM. It sure is more complicated than simply modifying a decompressed map in RAM.

Optimizing things is very fun. Check out my bytecode compiler. It's bursting at the seams with little tricks. I love playing the size-vs-speed game of balance in my head and I think I'm really good at it.

But I'm not interested in playing with the hardware. I want to make a game - a good one. The RAM gives us options. Better to be forced to optimize things to get costs down when the time comes than to force ourselves to develop something within a too-constricted space. Code can be replaced. Better to evolve from simple, stupid code because you narrowed down the scope to something that can be more efficient, than throw away something you spent days on because it was too limiting, creatively, or you decided to switch direction all together. I want to get to the creative "point B" faster more than I just want to diddle with the keyboard being clever - the RAM will help.

In case anybody is wondering, I went with Mapper 2 with 8 banks for now (128KB), CHR RAM and PRG RAM enabled. It works in Nintendulator and Nestopia. However Nestopia complains about garbage data in the header before starting the program.

Here's my header - if anyone can point out anything I'm doing wrong...

Nestopia does not understand iNES byte 10. Because one of the last 6 bytes were set, it clears all of bytes 7-15, so the part where you're getting PRG-RAM is intrinsic.

Really, use NES 2.0.

thanks, doing that solved it.

Funny, I'm the exact opposite. I would rather mess around with the hardware, but I have tremendous respect for those who work with the software. Maybe when you are getting closer to working out bugs and want to start heading down the hardware development side, I might be able to help.

I have been reworking SOROMS into SXROMS. Specs here:
http://bootgod.dyndns.org:7777/pcb.php? ... ID=393+394
These are the only easy way I have found to make them them as Retro no longer makes MMC1 repro boards.
Obviously you could run your own series of PCB's if you were really serious. I use board level sockets so you could even just distribute ROMS later on if you wanted to release another title without nearly the same expense as reproducing the cart all over again. These also use the ciclone chip so you could handle the different cic chips. I would be glad to help try to at least proto a few so you could make a better decision down the road

Here are a couple of pics converting SOROMS to SXROMS.

You got your quotes wrong... sonder said that, not me. =)

I'm very interested in how the hardware works, and how its design affects the software side of things. I don't have enough training or experience with electronics though, so my hardware projects are all very simple... soldering/desoldering, rewiring pins, installing switches, occasional console mods... I wish I did knew enough to design my own complex mappers and all that. But software will always be my main focus! =)

BTW, your board looks great! Very professional work there.

Oops, yep, sorry about that. Fixed.

Thank you for the comment.
It's like everything else. Whatever you work at the better you get. I just have more interest in the hardware.
I have seen some great advancements in emulators over the years and I know they are invaluable for testing, they just don't have the same feel
for me. So, I find myself gravitating back to hardware with all of it's quirks and limitations. I would point out the obvious in that
as we move forward to 'everything on one chip' I see this process fading away fast. Once these chips are gone, they will be gone
forever. I don't see a resurgence going back to this technology any time soon.

What do you mean? The NES's hardware (CPU, PPU, etc?) or cartridges/mappers?

There are already clones, flashcarts, and reproductions of all that available for purchase today. Unless I don't understand what you're referring to, there's already been a resurgence...

Resurgence of the ORIGINAL technology! EPROMS are going away forever and will not return. It is already getting hard to find old/new stock of certain sizes. Like 8 track tapes, if you liked them, you better go get them now, going, going gone.....forever. I'm not crying about it, just stating a fact. And while I'm there Nintendo on a chip? 90% there is still 90% if you are a fan, you know and if you don't know now you know. Close counts in horseshoes and hand grenades, not audio. Sorry, pretty picky about that last one. My site btw...
http://www.Ninstrument.com

</end of hijacking thread>

Re highjacking:

They aren't going away. CMOS EPROMS are. But Flash is the new tech and I don't see them going OOP for a while. 2KB sizes and such, yeah, never again. 32KB+ you'll be fine.

I get that especially with the Audio, but there are hopes for 100% in the foreseeable future. Clone makers don't care that much, but that doesn't mean someone that did care couldn't to it.

EPROMs disappearing is arguably a good thing just based on bit-rot. Flash is cheaper and better anyways if you can shift way from 32pin DIPs.

Socketed ROM days are numbered. The die plans of most Chinese manufacturers are all going surface mount. Will you be able to find them in 10 years, sure, but at what price. If recent years are any indicator, expect to pay. As the demand goes down for any component, you find the same thing. Look at prices for through hole RF chokes for instance. Ridiculous!

PURCHASE. MUST HAVE!!! HURRY UP!!! BRAND NEW!!! When you or someone else say so, think about this....

To estimate how much one would have to care: How many hundred thousand dollars would it take to go from Verilog on an FPGA to an accurate NOAC ASIC?

Doesn't really require much money aside from whatever tools are needed for development. Time is the biggest investment. You just need someone with the skills to be interested in developing it. The trick at that point is to take the necessary (often negelected) step of taking it to market. How does kevtris' APU stack up against the NES's? I'm sure it's next to flawless, or could be if he was motivated to make it so. The gap that's really missing is getting his NOAC to market which has it's own set of hurdles. I suppose that's where the biggest financial hurdle is, taking the little piggy to market. Hard to say what that cost would be exactly, depends greatly on how one were to do it.

Well seems like this didn't work ... my SRAM is coming back all seemingly-random indentical values (usually $FC though) anyone have any idea?

Have you tried clearing the identical values in your NES code and then looking at the resulting .sav in a hex editor?

i'm looking at the memory in FCEUX. whenever i pause emulation all the values change in tandem. i'm not using PRGRAM at all in the game yet.