nesdev.org

Because "powerful" and "inexpensive" rarely meet in this case. That's the trade-off. CPLDs are quite expensive when you want MMC3 functionality or beyond. TTL logic is equally expensive when getting complex, and akward to route. Full-custom ASICs are inexpensive to produce in larger quantaties, but it will cost you a fortune to setup manufacturing of them. And unless you have prior experience in ASIC design, something is likely to make the ASIC screw up in the first run.

For a really powerful mapper at an "acceptable" price tag, I think something like the flash-based ProASIC FPGA would do. It has the traditional drawbacks of not being 5V tolerant though, and you won't get below $10 a piece even for larger quantities.

Because "powerful" and "inexpensive" rarely meet in this case

Couldn't have said it better! Just for some examples, MMC1 size cpld is ~$4. MMC3 size cpld is ~$15. MMC3 size fpga is cheaper (~$10) but then you need to add boot rom, voltage translation, etc.

The old mappers (U*ROM, A*ROM, etc) are still used because emulators properly support them with no work, and the chip is incredibly cheap at $0.25. If you need wram then you can bump up to MMC1 for still relatively cheap. If you need more, buy a PowerPak

Personally I think MMC1 should be the maximum target for most starters. It can be put on brand new hardware and is simple so the game will hopefully stay simple (and be finished!).

I find Jagasian's point persuasive. A cheap and easy-to-emulate-accurately mapper would be ideal for modern NES development. Someone on 6502.org posted that the SX series microcontrollers can be had for under $3 a piece and run at 75 MHz, allowing them to emulate a programmable logic device plenty fast for a NES. These devices work on the principle that instead of having dedicated hardware, you just do almost all of it in software using a high clock rate.

MMCs are standard setup for the NES, so it definitely make sense to continue to use standard setups, and avoid complications, such as making super-bizare mappers made up just to have the desired features while being cheaper.
Plain discrete logic can still do great stuff, the only real problem is that features will eventually grow up a enourmous number of chips, and that it's a bit hazardous to route. (but nothing beats quad SMD chips when it comes to be horrible to route).

blargg wrote:I find Jagasian's point persuasive. A cheap and easy-to-emulate-accurately mapper would be ideal for modern NES development. Someone on 6502.org posted that the SX series microcontrollers can be had for under $3 a piece and run at 75 MHz, allowing them to emulate a programmable logic device plenty fast for a NES. These devices work on the principle that instead of having dedicated hardware, you just do almost all of it in software using a high clock rate.

I think this is a very interesting area to pursue.

I remember reading that Hellraiser for NES was designed to have a Z80 onboard (and thats around 2.5 MHz).


Al

Hey, sorry, I just missed that quote.
I think a x32 PLL multiplier on the M2 line would allow the microcontroller to run at 57.8 kHz on NTSC and 52 kHz on PAL, wich would be somewhat great. It couldn't react imediately unfortunately, but if the software would slow down it's mapper writes especially for the cart, it could be compatible with both the micro cart and the real (MMC1, MMC3, etc...) cart, making interesting things.

These devices work on the principle that instead of having dedicated hardware, you just do almost all of it in software using a high clock rate.

That's quite true : I don't know why most microcontroller on the market are equiped with that much I/O port integread functionality, serial bus interface, etc... when all this will not be simultaneously used 80% of the time and can be done by software. Just to keep lazy people rest lazy and just do some register writes instead of doing actual coding. Features like A/D converters and such cannot be replaced with soft, tough (but couldn't be interesting to use as mapper).
Anyway even if such a micro would be used, some features, like mirroring control and bus conflicts disabling couldn't be done without some discrete logic arround, because the mappers output really needs to directly react to the inputs.

The point is that you use a fast, cheap microcontroller in place of an FPGA to reduce cost, nothing more. It's just to provide simple functions like scanline IRQ or bank switching, not extra processing. And then we'd come up with an easy-to-use design so that every homebrew developer could use the same mapper, not make a bunch of custom mappers as Bregalad thought I meant.

It could be nice if a microcontroller could be synced with the NES CPU. I'm definitely not an oscillator expert, but I'm kinda skeptical that a PLL on the M2 clock at such high speeds would be practical.

Memblers wrote:It could be nice if a microcontroller could be synced with the NES CPU.

Hmmm, I take it you're implying there would be metastability issues if it ran on its own clock? Or that it wouldn't respond fast enough if no synchronized?

blargg wrote:

Memblers wrote:It could be nice if a microcontroller could be synced with the NES CPU.

Hmmm, I take it you're implying there would be metastability issues if it ran on its own clock? Or that it wouldn't respond fast enough if no synchronized?

I was mostly thinking of how the code would synchronize, which could either be lazy, or necessary, depending on how problematic any timing mis-step would be (haven't thought it through fully, heheh). Kind of like how people using an MCU for bit-banged RS232 would sometimes use a clock that gives a whole number of CPU cycles for each bit that comes in. That would practically eliminate framing errors, plus make the code a cinch to write.

I'm also thinking, with the way oscillators start up (varying with temperature and such, even more with a PLL) they won't start on the same cycle. I guess if it's fast enough it'd be able to get an input from the NES and go from there though. And also that 2 different oscillators will drift apart from eachother over some period of time. Maybe not a problem again, for the same reason (great speed difference and waiting for NES input).

I had thought about trying a similar experiment on Squeedo, for doing something like "fast block transfers" (forgoing IRQs on both CPUs) where the NES could just read/write as fast as possible while the PIC struggles to keep up and not drift into timing errors. I never got around to doing that though.

It does sound like a good idea. The designers at 6502.org have the luxury of clocking the CPU with their microcontroller, though. Sure is easy when you can just change everything around.

blargg wrote:The point is that you use a fast, cheap microcontroller in place of an FPGA to reduce cost, nothing more. It's just to provide simple functions like scanline IRQ or bank switching, not extra processing. And then we'd come up with an easy-to-use design so that every homebrew developer could use the same mapper, not make a bunch of custom mappers as Bregalad thought I meant.

You mean agree on a final mapper that would have enough features for everyone and then stick on it ? The MMC5 has almost all features one can think of, while being able to simulate lower features of lower mapper at almost perfection, would it be the universal mapper you're talking about ?

A MCU based mapper running with a PLL clock should definitely check for another thing at start-up to snch with the CPU (such as a simple rising edge of M2 or something in that sense). Then the mapper would have something like 32 cycles for each CPU cycle, maybe it's just enough to check if the mapper is written to and then react more or less immediately to it (some delay cycles woudldn't mapper when it comes to bankswitching). The problem is that mirroring control and CHR bankswitching should by synched with the PPU, wich is much faster than the CPU.