My own custom mapper design

[zzo38]

I have some ideas to make a custom mapper, which can be implemented using hardware as well as with DotFami. It would be 60-pins (I prefer the 60-pins cartridge; also it uses audio), and you use adapter for 72-pins.

Here is currently ideas:

• RAM from $5000-$5FFF, consisting of: name table, attribute table, general purpose.
• One register writes nametable mode: horizontal mirror, vertical mirror, cartridge RAM.
• 2K, 4K, or 8K CHR ROM. No bankswitching (except in attribute tables; see below). If there is 2K only, then only one plane is used for each tile (other is always zero), and it is mirrored in both pattern tables. 4K uses two planes and is mirrored in both pattern tables.
• Up to 64K PRG ROM, with 16K bank in $8000-$BFFF switchable and $C000-$FFFF switchable, by writing the low bit of any address in the range.
• At power, both ROM banks are reset; at soft reset, top ROM bank is reset only.
• Attribute table correspond to the name table byte for a single tile, using: bit0 = set to do IRQ while rendering this tile (for all eight scanlines). bit1 = unused (but exists; can be read by CPU). bit2, bit3 = palette selector. bit4, bit5, bit6, bit7 = if reading pattern table 0, then change the address as follows: If plane 0, use bit4 to select pattern table and bit5 to select plane number. If plane 1, use bit6 and bit7 in this way. If pattern table 1 is requested by the PPU, then do not use these bits at all.
• One register read for hardware random numbers.
• Memory $6000-$7FFF mapped to external memory card (optional feature).
• Four audio channels, all operating in the same way, with two registers each: Twelve bits of period and four bits which are AND by waveform data.
• Waveform data register you write four-bit values in series, sixteen in total.
• 2A03 audio can be either mixed with or amplitude modulating cartridge audio, depending on setting of a register.

I think this is all of it.

(Note: The only NES/Famicom hardware I have is a Famiclone device; I have counted the pins and I think there are sixty. I have no cartridges but it has some games built-in, some of which seem to have errors in them.)

[socram8888]

Personally I don't see the point of using a hardware RNG. The RAM at startup is AFAIK at a random state, so you can just leave a part of RAM untouched and use mathematical methods to derive those random bits to numbers of a certain length, much like a Mersenne Twister.

[tokumaru]

2K, 4K, or 8K CHR ROM.

Why would you have such limited CHR capabilities? Are you really gonna sacrifice mapper resources for making the CHR worse than it is in NROM? That makes no sense.

Up to 64K PRG ROM

Again, why such a small limit? What kind of games are you expecting to use this mapper for?

Attribute table correspond to the name table byte for a single tile, using: bit0 = set to do IRQ while rendering this tile (for all eight scanlines). bit1 = unused (but exists; can be read by CPU). bit2, bit3 = palette selector. bit4, bit5, bit6, bit7 = if reading pattern table 0, then change the address as follows: If plane 0, use bit4 to select pattern table and bit5 to select plane number. If plane 1, use bit6 and bit7 in this way.

Some interesting ideas here, but why all the complicated stuff with planes? Those bits would be much more useful if they increased the range of the tile index (allowing you to access 4096 tiles, or 8192 if you make use of that unused bit as well).

One register read for hardware random numbers.

Implementing a PRNG in software is pretty simple, no need to waste hardware resources on this just to save a few dozen CPU cycles here and there.

EDIT: Also, you are talking about these features but you are not explaining how they'll be implemented in hardware. This is an important step in inventing new mappers, because you need to be sure that the features are indeed feasible.

[tepples]

The least feasible thing I see there is mapping nametables into $5000-$5FFF. That'd need some sort of dual-ported RAM.

2 KiB CHR means skipping PA3 and PA12. 4 KiB CHR means skipping PA12.

Handling an attribute per tile involves either A. MITMing the whole PPU side of the cart bus like the MMC5 does and putting the read nametable address into a latch, or B. using a 16-bit RAM (or a separate 8-bit RAM as in the Super NES) and putting the upper 8 bits of data into a latch. The layout of these attributes is roughly as follows (correct me if I'm wrong:

Code: Select all

7654 3210
  || || |
  || || +- Clear a flip-flop whose output goes to /IRQ
  || ++--- Color set, repeated 4 times on the data bus during the attribute read
  |+------ CHR ROM A12
  +------- CHR ROM A3

[Hamtaro126]

Famiclones are really not a good thing to use in this case, Using Real Hardware is recommended, MMC5 for example did not work on most Famiclones proper because of inaccuracies in NES-on-a-Chip hardware...

Also, In place of the Audio stuff you mentioned, Why not use WAV/MP3 for both sound and music instead, I'll understand if it is too big!

[zzo38]

Also, you are talking about these features but you are not explaining how they'll be implemented in hardware.

Yes; I do intend to do this too. (I intend to make the DotFami format to describe the hardware, and emulate it (this way, games using custom mappers can still run on emulators! I do not want to require everyone to purchase the cartridge in order to use it), and then it can be checked by building hardware as well.) (Also, DotFami mapper codes )

Implementing a PRNG in software is pretty simple, no need to waste hardware resources on this just to save a few dozen CPU cycles here and there.

OK. Perhaps hardware random numbers can be omitted.

Some interesting ideas here, but why all the complicated stuff with planes? Those bits would be much more useful if they increased the range of the tile index (allowing you to access 4096 tiles, or 8192 if you make use of that unused bit as well).

At least when I have thought of stuff, I have found that I wanted to change the color of tiles. A variant with more CHR ROM would use those bits for other purpose to select CHR bank.

Why would you have such limited CHR capabilities?

I wouldn't need that much...especially for such thing as CP437 (such as ZZT-like stuff). For more complicated thing you could have a variant with 32K CHR ROM! You could say there is no use for 2K and 4K CHR ROM in emulations (always using 8K or more) and just omit some pins (so there will be mirrors) when using an actual ROM chip having less address pins (although you could also use the full 8K ROM chip if it is what you happen to have available when building the hardware).

Again, which such a small limit?

I wouldn't think you need more than that; but I suppose it can be variant with more if you have two bits of bank, or mapping $6000-$7FFF to some extra PRG ROM (if the optional memory card feature is not used), etc

The least feasible thing I see there is mapping nametables into $5000-$5FFF. That'd need some sort of dual-ported RAM.

Yes, that is what I thought.

2 KiB CHR means skipping PA3 and PA12. 4 KiB CHR means skipping PA12.

Yes basically; when using the cartridge attribute tables though, the extra space should be treated as zero; when not using these, they could be mirrors if it is simpler to implement.

Handling an attribute per tile involves either A. MITMing the whole PPU side of the cart bus like the MMC5 does and putting the read nametable address into a latch, or B. using a 16-bit RAM (or a separate 8-bit RAM as in the Super NES) and putting the upper 8 bits of data into a latch. The layout of these attributes is roughly as follows (correct me if I'm wrong:

Code: Select all

7654 3210
  || || |
  || || +- Clear a flip-flop whose output goes to /IRQ
  || ++--- Color set, repeated 4 times on the data bus during the attribute read
  |+------ CHR ROM A12
  +------- CHR ROM A3

Yes, it would be probably implemented using 16-bit RAM or two 8-bit RAMs. And yes you basically have the ideas of attribute table good, except for bits 6 and 7. In addition, bits 4 to 7 are only used when the PPU requests pattern table 0 (even if it actually causes pattern table 1 to be read); this way pattern table 1 can be free for sprites. Therefore you can: Change the colors of tiles (allowing 13 colors), use more tiles available on background, etc. (For the above mentioned variant of more than 8K CHR ROM, these could select the CHR bank.) Using one bit of attribute for IRQ allow you to do stuff before vblank if it help. (Another idea I have, but which may not be needed, is using different palettes for different scanlines! This may be too complicated though.)

I will write more later.

P.S.: Also a question: Does the 2A03 audio include a DC offset?

[infiniteneslives]

Is there a specific purpose to this mapper? Most of the things just seem pretty random to me so I'm wondering where the motivation is coming from...

If you really want to see this on hardware I think your game plan might be a little backwards. Mainly not considering hardware needs/costs until you've already make the mapper in an emulator and such. If you're experienced with logic design and HDL there's really only one part that would make this feasible, namely the Lattice Mach X02. With current prices and required supporting hardware you're looking at ~$10 -15 in hardware for very fine pitch BGA packaged parts. Unless you've got lots of experience with this type of assembly you'll be paying someone a few more dollars for assembly. So even produced in large 100-500 quantities you're looking at around $25 for board and mapper assuming you have required design skills to make that happen.

Not trying to burst your bubble or anything, it is possible and within reason for cost if done properly. I guess I just don't see the things your talking about being worth ~twice the cost of a more traditional mapper. Your ideas wouldn't come close to touching the capabilities of the hardware I'm suggesting. If you were to make full use of that hardware, you'd appeal to more people, and could more easily justify the added cost of the required hardware. If this were something like a easily programmable dev cart it'd be more appealing as well, but it sounds like your just looking to produce games with this board.

[zzo38]

Well, if I make up DotFami specification well enough, then we can emulate these mappers. For now I could use whatever other mapper is suitable for the project. I have no intention to sell the games, but other people can put on a cartridge if they want to.

[tepples]

If you're making something to run only in an emulator, you might as well write it in Java. That runs in an emulator too

[zzo38]

If you're making something to run only in an emulator, you might as well write it in Java. That runs in an emulator too ;-)

Well, I intend it to run on the actual hardware too, not only in emulators. It is just that I do not intend to sell the hardware myself; people can build it themself if they want to run on the actual hardware (if I ever do want to sell the game, then I will build the hardware myself too, as well as including a computer file (both the ROMs and mapper codes) if you want to run on emulator).

[rainwarrior]

Unless you've got the resources to make a game or other NES software that makes worthwhile use of every feature of this mapper, I don't really see the point in designing it. Wouldn't it make more sense to start creating your game, and add features to your custom mapper only as needed? It's really easy to mix and match fun mapper features on paper. Actually making use of it is the difficult part, and really the only thing that can make the mapper itself worthwhile.

If it's not designed to make running existing software easier (like infiniteneslives' MMC3 compatible board), what use do you expect this mapper to have? It's not like we have a high volume of homebrew NES software coming out, and most of the people who actually are making NES software seem to be content with existing mappers (and usually target simpler mappers to keep costs down).

Sorry if this sounds harsh, but I don't understand your goal in designing this mapper. What practical problem does it solve?

[zzo38]

Sorry if this sounds harsh, but I don't understand your goal in designing this mapper. What practical problem does it solve?

Some problems I have had in writing down design for some games, seem would be useful these features. Of course I can target other mappers for things that can use it. This was just my idea; it may not get built or used but is just ideas I had, when thinking of what mapper feature would help with some game idea I had.

[rainwarrior]

Well, this community needs more quality software, so if you've got a good game idea, I highly encourage you to start programming it.

If your game is good and it needs a custom mapper, emulator authors might be willing to implement it, but if you've got no game, nobody will care about your mapper.

People out there can correct me if I'm wrong, but I don't think anybody who is actually actively making NES software isn't going to be hung up on a mapper not having just the right features. If you hit a stumbling block when making a game, usually there are less drastic solutions than designing a custom mapper. Also, the majority of homebrew NES stuff runs on NROM anyway. Even in original NES games, the most complicated mappers (e.g. MMC5, VRC6, VRC7, FME-7, 5B) were used in very, very few games!

Anyhow, what I'm suggesting is that you start working on your game instead. Don't worry about a custom mapper; design that if/when you find that your game needs it.

[zzo38]

Yes; I could also use MMC5 if it needs 8x8 attributes and extra audio. (If using any complicated mapper and not all features are used, the features used could be specified in a README file, so that a less complicated cartridge can be used.) If it is not needed, other mappers can be used; in many cases, NROM is good enough. (In a project I am working on at this time, NROM is more than sufficient. In another idea, I planned it on paper it seem this my idea of mapper would help.)

For implementing the mapper, I had no intention that any emulator authors would implement this mapper; instead, they should be a DotFami mapper code, and have the emulator include a compiler from DotFami mapper codes into native code, and emulate the mapper that way instead.

[3gengames]

Might as well make it 5000-7FFF for the RAM, although I think you should just use banks of 8KB in the pre-defined space and make 2 for the stuff you need..