More complex mappers

[naI]

Split from here

Thank you, loopy! This is a wonderful development!

I must say, Gradius II is truly an impressive port for the Famicom hardware. I enjoyed the music and the smooth visuals. The difficulty is crazy, though, even compared to the intensity I would've expected. I only passed the first stage. Truly a hardcore, feature-rich game for the Famicom with a wonderful interpretation of the music.

Now the main breakthrough we should wait for is MMC5 support. (...and, of course, VRC7 if possible) I would like to see the homebrew community become more accustomed to complex mappers that can help to push the capabilities of the system. Perhaps some of the seasoned coders here will be able to take on grander projects that will make use of more sound channels, more objects on screen, more advanced bank switching, etc.

[tepples]

I would like to see the homebrew community become more accustomed to complex mappers

NES development isn't a day job. But as of right now, if a game uses anything more complex than MMC1, a developer can't even make a token effort to recover costs and put a "commercial title" on his CV by selling copies on RetroZone.

Perhaps some of the seasoned coders here will be able to take on grander projects that will make use of more sound channels

IRQs to funnel audio from the cart into $4011 would eat a lot of CPU time. I could resistor mod my NES for Famicom sound, but that doesn't work on my cousin's NES and my cousin's friend's NES that aren't resistor modded.

more objects on screen

The NES PPU has a limit on sprites per scanline. Did you mean a mapper with its own PPU, like Wide Boy?

[tokumaru]

more objects on screen

The NES PPU has a limit on sprites per scanline. Did you mean a mapper with its own PPU, like Wide Boy?

That wasn't fair, tepples... He might have said that because of the MMC5, which can't increase sprite count but can increase the amount of available tiles for sprites and background, allowing one to draw a larger number of different objects (even if it means using the background).

[naI]

more objects on screen

The NES PPU has a limit on sprites per scanline. Did you mean a mapper with its own PPU, like Wide Boy?

That wasn't fair, tepples... He might have said that because of the MMC5, which can't increase sprite count but can increase the amount of available tiles for sprites and background, allowing one to draw a larger number of different objects (even if it means using the background).

Yeah, I wasn't specific enough. I was specifically thinking about the capabilities of the MMC5 when I said that. Sprites per scanline is a different matter that can't be overcome with conventional mappers.

NES development isn't a day job. But as of right now, if a game uses anything more complex than MMC1, a developer can't even make a token effort to recover costs and put a "commercial title" on his CV by selling copies on RetroZone.

My intention wasn't to be a script kiddie begging for the games tomorrow. I'm merely optimistic about the opportunities for innovation that the NESDev community has.

[kyuusaku]

The PowerPak does offer a lot of hardware power to homebrewers but remember if someone wants to publish their game, fancy stuff doesn't fit into discrete logic or even CPLD. So at least in my case, there's little motivation to stray from conventional hardware options.

[MottZilla]

Couldn't you split things up and use 2 CPLD then? Or would the cost of more than one CPLD be too much for cost?

I think it's like a Catch22 thing where people don't see much point in making an original game using a more advanced mapper because there is no reasonable means to make cartridges and sell them but there is not much reason in making boards for more advanced games when no one is known to be working on and in need of one.

[tepples]

So I guess someone should develop a game that can be built for MMC1 or MMC3 as a compile-time option, enabling extra features in MMC3 mode. Would that kick-start demand for an MMC3-class mapper?

I smell split. Can anyone tell me where?

[kyuusaku]

Couldn't you split things up and use 2 CPLD then? Or would the cost of more than one CPLD be too much for cost?

I think it's like a Catch22 thing where people don't see much point in making an original game using a more advanced mapper because there is no reasonable means to make cartridges and sell them but there is not much reason in making boards for more advanced games when no one is known to be working on and in need of one.

Two large CPLD (100+ register) wouldn't be able to fit the full MMC5 with multiplier and EXRAM or a REALLY complex sound chip, but together they may be able to fit some basic fancy stuff like mid-screen interrupts.

The PowerPak's FPGA is very roughly equivalent to 15 CPLD (there's a lot of overhead in the design) with 3K of internal RAM in smaller blocks. Surely the better part of an Atari 2600 can fit in the PowerPak's FPGA.

I smell split. Can anyone tell me where?

naI's post about more complex mappers?

[tepples]

There appears to be a demand for more powerful mapper designs that will fit in a CPLD. One could start by taking MMC3 and stripping it down, or one could start from the ground up. As I understand it, the "capacity" of a CPLD is measured in macrocells, which roughly correspond to bits of state. NovaYoshi and I were brainstorming one day about ideas for NES mappers that could achieve MMC3-like effects while using MMC1-like macrocell counts, and we came up with this.


CPU side: Up to 512 KiB of PRG ROM
$8000-$BFFF: switchable in 16 KB banks
$C000-$DFFF: switchable in 8 KiB banks, primarily for sampled sound
$E000-$FFFF: Fixed to last bank
IRQ: Triggered by PPU tile $FF

PPU side: 16 KiB of CHR RAM
$0000-$1BFF: Fixed
$1C00-$1FFF: Switchable, primarily for background CHR animation

In: 20 pins
+5V, GND; PPU A13-A4; CPU A14-A13, D4-D0, PRG /CE, R/W, M2

Out: 12 pins
CHR RAM A13-A10; PRG ROM A17-A13, /OE; PRG RAM /OE, /WE
(CHR A10 goes to both CHR RAM and CIRAM; PRG A13 goes to both PRG ROM and PRG RAM)

State: 20 bits
(19 bits for bank registers, 1 bit for IRQ state)

Memory map:

Code: Select all

7654 3210  $8000: First PRG bank
   | ||||
   +-++++- Select 16 KiB bank 0-31 of PRG ROM in CPU $8000-$BFFF

7654 3210  $A000: CHR control
   | ||||
   | |+++- Select 1 KiB bank 8-15 of CHR RAM in PPU $1C00-$1FFF
   +-+---- Select mirroring, like MMC1
           0: one-screen from first bank;
           1: one-screen from second bank;
           2: vertical; 3: horizontal

7654 3210  $C000: Second PRG bank (used especially for DPCM)
   | ||||
   +-++++- Select first half of 16 KiB bank 0-31 of PRG ROM
           in CPU $C000-$DFFF

7654 3210  $E000: IRQ and PRG RAM control
   | || |
   | || +- 0: Assert IRQ upon PPU $0FF0-$0FFF or $1FF0-$1FFF access
   | ||    1: Acknowledge and disable IRQ
   | |+--- 0: Enable reads to PRG RAM in $6000-$7FFF
   | +---- 0: Enable writes to PRG RAM in $6000-$7FFF
   +------ Select 8 KiB bank of PRG RAM in $6000-$7FFF

[tokumaru]

NovaYoshi and I were brainstorming one day about ideas for NES mappers that could achieve MMC3-like effects while using MMC1-like macrocell counts, and we came up with this.

I'd be interested in such a mapper.

Up to 512 KiB of PRG ROM

Can't you increase that somehow? Considering that this uses CHR-RAM, 512 KB for both PRG and CHR isn't really that much. Enough for many types of games, but discourages certain types of experiments (video and audio playback, for example) or anything that dares to go a bit beyond the standard set in the early 90's.

IRQ: Triggered by PPU tile $FF

This is a very interesting idea, and sounds simple enough. I like it. it's like a sprite 0 hit done right.

PPU side: 16 KiB of CHR RAM
$0000-$1BFF: Fixed
$1C00-$1FFF: Switchable, primarily for background CHR animation

Still doesn't help much with large main characters with many animations... I don't have a better suggestion though, I know it would take a lot of bits to have small CHR banks.

[tepples]

Up to 512 KiB of PRG ROM

Can't you increase that somehow?

It's already bigger than Super Mario Bros. 3 and tied with SUROM games. But an iNES PRG segment can't be bigger than 256 * 16384 bytes or 4080 KiB, and rounding that down to the next lower power of 2 gives 2048 KiB. I could bump up the mapper to 2048 KiB using four more register bits, two more inputs (D6-D5), and two more outputs (PRG A19-A18).

PPU side: 16 KiB of CHR RAM
$0000-$1BFF: Fixed
$1C00-$1FFF: Switchable, primarily for background CHR animation

Still doesn't help much with large main characters with many animations

It's intended for background use. Watch Super Mario Bros. 2 or 3 in an emu with a pattern table viewer (e.g. Nintendulator, PocketNES in VisualBoyAdvance, or even NESticle) and look at what happens to all the coins, ? blocks, etc. For sprite animations, do what Battletoads does: a big unrolled loop to blast a bunch of bytes at once from a buffer in stack space.

... I don't have a better suggestion though, I know it would take a lot of bits to have small CHR banks.

Thank you for your feedback.

[tokumaru]

It's already bigger than Super Mario Bros. 3 and tied with SUROM games.

I consider it irrelevant to compare it to the old commercial games. Whenever I think of mapper features I'd want, I think of everything I wanted to do at some point but couldn't because of one limitation or another. If we keep aiming only at the old NES games we will never surpass them, and I really believe we can innovate and do more. And more PRG space is not so hard to provide and can make all the difference, IMO.

I could bump up the mapper to 2048 KiB using four more register bits, two more inputs (D6-D5), and two more outputs (PRG A19-A18).

I'd really appreciate if you could do this. I just hope it still fits the CPLD.

Watch Super Mario Bros. 2 or 3 in an emu with a pattern table viewer

I'm familiar with the effect, and I agree that this part is covered, I was just pointing out another common problem, one that newer games solved by dedicating a 1KB slot in the CHR area to the main character and switched in the appropriate data depending on the character's animation frame.

But like I said, I cant think of a simple way to solve this problem. It seems that with this mapper I can only pick one to use bankswitching for: the main character or background animations.

For sprite animations, do what Battletoads does: a big unrolled loop to blast a bunch of bytes at once from a buffer in stack space.

Yeah, my current approach is similar to that. But depending on the amount of background tiles that animate, it would make more sense to update them with the unrolled loop and dedicate the bankswitching to the main character. Hey, at least we have a choice!

BTW, I don't think using the stack is much of an advantage in this process, as PLA takes the same amount of time an indexed load does, so as long as the data is stored interleaved in the ROM (and properly aligned) you can copy directly from it just as fast, without wasting time using the stack as an intermediary. The only disadvantage is that an indexed load is 3 bytes long, and PLA is just 1, but if you're unrolling code you probably have a lot of space for it (and you can partially unroll it without much performance penalty).

[tepples]

I could bump up the mapper to 2048 KiB using four more register bits, two more inputs (D6-D5), and two more outputs (PRG A19-A18).

I'd really appreciate if you could do this. I just hope it still fits the CPLD.

An MMC1 appears to take 25 bits (20 bits of registers, 5 bits for the shift register), so we're probably still under the limit.

I was just pointing out another common problem, one that newer games solved by dedicating a 1KB slot in the CHR area to the main character and switched in the appropriate data depending on the character's animation frame.

Yeah, I've seen that in SMB3 too. But I see a few drawbacks:

• It'd be a few more bits to add a second swappable CHR bank. Exactly how many macrocells are in the sort of CPLD used for the RetroZone MMC1?
• I'd need PRG A12 and possibly an additional CHR RAM address line.
• Player 2 might still need a CHR bank.

By that time we might as well make a full MMC3.

BTW, I don't think using the stack is much of an advantage in this process

A couple (unreleased) projects I've worked on use indexed loads from $0100-$019F, unrolled by a factor of 16 or 32.

[tokumaru]

An MMC1 appears to take 25 bits (20 bits of registers, 5 bits for the shift register), so we're probably still under the limit.

Awesome! The small ROM size was the biggest drawback in my opinion.

It'd be a few more bits to add a second swappable CHR bank.

Although that would be the best option, I can understand if it's not possible.

Exactly how many macrocells are in the sort of CPLD used for the RetroZone MMC1?

Hopefully bunnyboy can answer this.

Player 2 might still need a CHR bank.

Well, with 2 slots something has to give. If you really need 2 players, you can use 8x16 sprites and the background tiles will have to be updated manually. At least you get to choose how to use your resources.

By that time we might as well make a full MMC3.

Please don't, you're so close to defining a good yet simple enough mapper, that is in a few ways even more versatile than an MMC3. Your IRQ idea is very interesting (although it has it's limitations), CHR-RAM with bankswitching allows for a lot of tricks, not to mention the larger PRG size.

A couple (unreleased) projects I've worked on use indexed loads from $0100-$019F, unrolled by a factor of 16 or 32.

But you still had to put the data in there, which must have took some time.

[kyuusaku]

Exactly how many macrocells are in the sort of CPLD used for the RetroZone MMC1?

Likely 36, but possibly 72 (which I think is used in the PowerPak Lite).