Modern Mapper Replacement Chips?

Discuss hardware-related topics, such as development cartridges, CopyNES, PowerPak, EPROMs, or whatever.

Moderator: Moderators

Mikey
Posts: 9
Joined: Thu Jan 05, 2023 12:35 pm

Modern Mapper Replacement Chips?

Post by Mikey »

I'm wondering if there are any popular re-implementation of mapper chips, like MMC3 or MMC5 (or even MMC1) that are approachable for hobbyists.

I'm interested in solutions that use PLA, CPLD, MCU (or even discrete 74LS00 logic) to implement common mappers. (Ideally with through hole components, but that's not a hard requirement.)

I'm pretty new to NES development, but I'd like to build a game that works both in emulators and on original hardware; and the scanline interrupt in the MMC3 sounded neat -- the MMC5 seems a bit more powerful though, so I'm most interested in that (with the ability to do different palettes for every 8x8 tile, instead of being restricted to 2x2 attribute chunks).

Are there more powerful mappers that added more features to the NES than these? Do any of them have a way of overcoming the 8 sprites per scanline issue of the PPU? (I know there's hundreds of mappers, I'm guessing there aren't any that get around the 8 sprites per scanline issue -- mostly just wondering which ones have the best features and support; both in modern hardware implementations and software).

(Also curious how things like the "YOU ARE ERROR" cartridge is able to get such good audio out of an unmodded front loader if anyone knows.)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Modern Mapper Replacement Chips?

Post by lidnariq »

In the distant past, MMC1, MMC3, VRC2, and VRC4 clones were made, all in DIP. However, we haven't seen the VRC2 or VRC4 clones in eons, and this New Old Stock of DIP MMC3 clones seem to have recently finally sold out.

You can still get New Old Stock of MMC1 DIP clones (e.g. https://www.etsy.com/listing/1238181548 ... cuit-board ).

Discrete logic mappers - and a few very simple ASIC mappers - can be made out of 74xxx parts.

And that's it for DIP options. Manufacturing moved away from DIP during the 1990s.

There's a modern MMC3 clone in TQFP or COB available from MindKids's store on AliExpress.

Otherwise, you're going to have to use programmable logic, in TQFP, QFN, or BGA. The MiSTer project is the best single source of Open Source HDL for the mappers, but you'll have to do a fair amount of learning and work to adapt that to a standalone CPLD/FPGA.

It's also a bad time to be looking into this - availability (and when you can get them, prices) on CPLDs and FPGAs has never been worse.
Mikey
Posts: 9
Joined: Thu Jan 05, 2023 12:35 pm

Re: Modern Mapper Replacement Chips?

Post by Mikey »

And that's it for DIP options. Manufacturing moved away from DIP during the 1990s.
Again, it's more of a preference than a requirement. -- I don't mind doing SMD stuff, as long as it's not BGA or something that needs special equipment.
It's also a bad time to be looking into this - availability (and when you can get them, prices) on CPLDs and FPGAs has never been worse.
I have a stock of lattice GALs floating around somewhere; but I'm guessing they probably would only work for very simple mappers; I know you could build an 8-bit counter with one chip, and maybe other bits of the mapper with additional 20V10 chips, but not sure how the MMC3 is actually counting scanlines from the cartridge port in hardware... -- But it would be kind of power hungry, and and there's probably bits that you just couldn't do in GALs alone.

I also have a ton of ATMEL and STM32 MCU chips floating around; I feel like those could be promising for more advanced mappers (I know krikzz has an ATTINY version of the CIC up on GitHub -- I know that's not a mapper; just kind of similar idea -- replacing a required chip with an MCU); I'm just wondering if any one has done one of the more advanced mappers without FPGAs.
There's a modern MMC3 clone in TQFP or COB available from MindKids's store on AliExpress.
Interesting thanks for the tip; I searched just now and found those -- but are they really clones? -- or scavanged from boards? -- Do they have the same pinout as the mmc3 chip in the wiki?

And does MindKid have a good reputation? -- There have been a lot of fake chips coming outof AliExpress... (re-lables of TQFP in the same form factor, etc.)

EDIT: Ahh, I see they claim it's their own clone and provide a pinout and specifications on product page. Neat! /EDIT

Any source of MMC5, or more powerful mappers?
he MiSTer project is the best single source of Open Source HDL for the mappers, but you'll have to do a fair amount of learning and work to adapt that to a standalone CPLD/FPGA.
Oh, that's a great idea!

I wonder also -- are there any open source rom carts that have wide mapper support? -- That would probably be the most useful thing to look at, I think -- since it's already kind of doing what I would need. -- (I'm guessing there's not, but who knows..)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Modern Mapper Replacement Chips?

Post by lidnariq »

Mikey wrote: Tue Jan 10, 2023 1:36 pm I have a stock of lattice GALs floating around somewhere; but I'm guessing they probably would only work for very simple mappers; I know you could build an 8-bit counter with one chip, and maybe other bits of the mapper with additional 20V10 chips, but not sure how the MMC3 is actually counting scanlines from the cartridge port in hardware... -- But it would be kind of power hungry, and and there's probably bits that you just couldn't do in GALs alone.
GALs are pedantically up to the task, but the largest ones (26V12) only ever had 12 "macrocells" - 12 bits of state, plus the AND-OR plane. Compare to MMC3 that has at least 85 bits of state, or even MMC1 with "only" 24.
I also have a ton of ATMEL and STM32 MCU chips floating around; I feel like those could be promising for more advanced mappers (I know krikzz has an ATTINY version of the CIC up on GitHub -- I know that's not a mapper; just kind of similar idea -- replacing a required chip with an MCU); I'm just wondering if any one has done one of the more advanced mappers without FPGAs.
It's usually a bad plan to use a microcontroller as a mapper - it's subject to extreme latency deadlines, and then you have an additional delay from an external memory? Best to just use the microcontroller as the whole ROM emulator ("ROMulator") in the first place.

Then you have different problems, of course, such as "just how much memory can your microcontroller address".

And in the NES's case, having two entirely independent clock domains (CPU and PPU are at a fixed ratio but not a fixed skew) makes emulating both on a single device almost impossible.
Any source of MMC5
No, and don't use MMC5 :P

Less glibly, it's underdocumented and we know there's sharp edges lurking (obliging you to use donors for bug-for-bug compatibility), it's a bad design for a mapper and you can get something dramatically more useful for less difficulty using programmable logic.
, or more powerful mappers?
I mentioned all the clones that I knew of. I guess pedantically there's been a VRC3 clone.
I wonder also -- are there any open source rom carts that have wide mapper support? -- That would probably be the most useful thing to look at, I think -- since it's already kind of doing what I would need. -- (I'm guessing there's not, but who knows..)
There isn't, because it's a shockingly huge amount of work and providing support is a nightmare. I think the MiSTer project is the closest to having the needed HDL all in a central repository.

Something like the iCE40HX1K that the EDN8pro uses to bootstrap is already more capable than the FPGA in the PowerPak, so it's not like this couldn't be done.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Modern Mapper Replacement Chips?

Post by tepples »

During this CPLD drought, is it a good idea to plan to use discrete mappers for new games?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Modern Mapper Replacement Chips?

Post by lidnariq »

In my opinion? Yes, that's a better plan.

The pipedream I've been playing with is a RP2040-based PRG ROMulator, with "just" coarse bankable CHR RAM. Should be in scope, cheap, and quite capable - but with very little of the classic CHR bankswitching animations.
Mikey
Posts: 9
Joined: Thu Jan 05, 2023 12:35 pm

Re: Modern Mapper Replacement Chips?

Post by Mikey »

Compare to MMC3 that has at least 85 bits of state, or even MMC1 with "only" 24.
Yeah, that's what I'm talking about, like sure... you could do it with a giant board full of GALs sticking out of your system -- it would just need its own power supply... and postal code. :lol:

That's why I'm here picking your brains... I don't feel like that's a reasonable solution, you know? :)
The pipedream I've been playing with is a RP2040-based PRG ROMulator, with "just" coarse bankable CHR RAM. Should be in scope, cheap, and quite capable - but with very little of the classic CHR bankswitching animations.
That's similar to what I'm talking about... but without the ROMulator... just PRG, and CHR memory devices, with an MCU that has a few "register" addresses for bank switching. -- I feel like timing wouldn't be cumulative in that scenario... like... it would still be tight, but... it should be more forgiving than a Romulator, because the memory devices are doing most of the work still. -- If it needs to assert values to the data bus (i.e. the CPU is trying to read a mapper register), it can set the /E high on the memory device at the same time that it writes the bits; so there shouldn't be any cumulative timing involved. -- Yeah the timing is tight, but less so than a Romulator since most requests it does nothing and only needs to be woken up by interrupt when specific addresses are queried.
I mentioned all the clones that I knew of. I guess pedantically there's been a VRC3 clone.
Well clone chips aside, what is the best mapper feature-wise? -- that like... has some semblance of being widely supported in emulators?
No, and don't use MMC5 :P

Less glibly, it's underdocumented and we know there's sharp edges lurking (obliging you to use donors for bug-for-bug compatibility), it's a bad design for a mapper...
I'm confused by this. -- Why would bug-for-bug compatibility with existing MMC5 chips be necessary in this scenario? (I understand why it's necessary if I was building a repro of an existing game or a knock-off everdrive or something... but this is for new development. -- As far as I know, it would just need to be bug-for-bug compatibile with whatever the popular emulators are doing -- and then it would run identically both in emulators and real hardware, right?) :?
...you can get something dramatically more useful for less difficulty using programmable logic.
That's kind of what I'm asking ... assuming I use programmable logic of some kind... for a new development... what is the most feature rich mapper? -- Like... what extends the hardware the most, and is also widely supported by emulators? (because again, I want to target both emulators and hardware.)

The reason I keep mentioning MMC5 is because it has some killer features -- like an 8-bit hardware multiplier -- and the ability to use distinct attributes for each 8x8 tile (instead of dealing with 2x2 tile macro blocks). -- Are there other mappers that can do that? -- Are there mappers that can do better? -- What are they?
Something like the iCE40HX1K that the EDN8pro uses to bootstrap
Holy cow... those are FPGAs... availble in single qty for only 6.65? ... and Digi-Key has thousands of them in stock? -- and it has an open source tool chain...?! :shock:

Edit: Looks like OLIMEX has the PCB for a dev kit up on github. Nice! /Edit

Heck yeah! -- I hadn't realized the barrier to entry on FPGAs was so low. That's really cool! -- I may need to dive down that rabbit hole! :D
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Modern Mapper Replacement Chips?

Post by lidnariq »

Mikey wrote: Tue Jan 10, 2023 9:11 pm but without the ROMulator... just PRG, and CHR memory devices, with an MCU that has a few "register" addresses for bank switching. -- I feel like timing wouldn't be cumulative in that scenario... like... it would still be tight, but... it should be more forgiving than a Romulator, because the memory devices are doing most of the work still. -- If it needs to assert values to the data bus (i.e. the CPU is trying to read a mapper register), it can set the /E high on the memory device at the same time that it writes the bits; so there shouldn't be any cumulative timing involved. -- Yeah the timing is tight, but less so than a Romulator since most requests it does nothing and only needs to be woken up by interrupt when specific addresses are queried.
Unfortunately, you're wrong - timing is simply cumulative.

On the NES, you have roughly 350ns from when /ROMSEL goes low until final data for the CPU must be valid.

If you use an external ROM - for the sake of argument, let's say one with 110ns cycle time - that reduces your timeline by those same 110ns, so you have to get a completely valid address to the ROM after only 240ns.

But if you can do everything inside the microcontroller, you have the entire timeline for the task. If you start doing some cycle counting, you'll see that this often works out better.

(Also: it turns out that interrupts on all microcontrollers are basically strictly out of scope. They just have too much jitter and/or too much latency.)
Well clone chips aside, what is the best mapper feature-wise? -- that like... has some semblance of being widely supported in emulators?
The one that the software that you want to run uses.

I know that sounds glib, but it's true. Features you don't need are wasted. Features you don't have are unusable. Don't use MMC5 because it's "the best". MMC5 is a kitchen sink of half-baked ideas, none of which are executed particularly usefully. The things that MMC5 does that other mappers do too were done more usefully and cheaper by those other mappers; the things that MMC5 does that are unique are needlessly crippled.
I'm confused by this. -- Why would bug-for-bug compatibility with existing MMC5 chips be necessary in this scenario? (I understand why it's necessary if I was building a repro of an existing game or a knock-off everdrive or something... but this is for new development. -- As far as I know, it would just need to be bug-for-bug compatibile with whatever the popular emulators are doing -- and then it would run identically both in emulators and real hardware, right?) :?
But that's just the problem! It won't. It can't. Currently, emulators only emulate the things needed by commercial games (and sometimes not all of that very well due to language barriers) because we haven't enumerated what things are. So if you write something that quacks like an MMC5 and we later discover it's not - you've just stuck yourself in a square hole for no virtue at all.
The reason I keep mentioning MMC5 is because it has some killer features -- like an 8-bit hardware multiplier -- and the ability to use distinct attributes for each 8x8 tile (instead of dealing with 2x2 tile macro blocks). -- Are there other mappers that can do that? -- Are there mappers that can do better? -- What are they?
I promise neither of those are anywhere near as amazing as they sound.

Fast 8×8→16 multiplies can be done not that much slower than the hardware multiplier by using the difference-of-squares method and a small lookup table, and the 6502 is memory bandwidth limited.

8x8 attributes on the MMC5 are strictly coupled to not having bankswitching animations. All the advanced PPU modes (left-and-right split, 8x8 attributes, 8 banks of 8x16 sprites) are strictly coupled to "not turning off rendering for a mid-screen palette change".
[iCE40HX1K-VQ100] available in single qty for only 6.65? ...
Note that for anything other than very specific models of PLDs (LC40xx, ATF150x) you'll have to add the cost of voltage translation. Usually 3V flash is cheaper, to help make up the cost difference, but recently that's been getting weirder.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Modern Mapper Replacement Chips?

Post by rainwarrior »

lidnariq wrote: Tue Jan 10, 2023 10:49 pmFast 8×8→16 multiplies can be done not that much slower than the hardware multiplier by using the difference-of-squares method and a small lookup table, and the 6502 is memory bandwidth limited.
Is this documented somewhere? How fast are we talking?
User avatar
Jarhmander
Formerly ~J-@D!~
Posts: 569
Joined: Sun Mar 12, 2006 12:36 am
Location: Rive nord de Montréal

Re: Modern Mapper Replacement Chips?

Post by Jarhmander »

An naive implementation of multiplication by difference of squares would use 512 bytes for a LUT (256 16-bit values), and would require an 8-bit difference+lsr, an 8-bit mean, 2 16-bits lookup and a 16-bit difference. In the ballpark of 50 cycles or so?
((λ (x) (x x)) (λ (x) (x x)))
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Modern Mapper Replacement Chips?

Post by rainwarrior »

Eventually found this on the wiki: https://www.nesdev.org/wiki/Fast_signed_multiply

I'm kinda surprised we haven't accumulated a reference unsigned 8x8=16 example of this on the wiki yet.
Drag
Posts: 1615
Joined: Mon Sep 27, 2004 2:57 pm
Contact:

Re: Modern Mapper Replacement Chips?

Post by Drag »

Remember, it's very easy to generate a table of squares:
12 = 1
22 = 1 + 3
32 = 1 + 3 + 5
42 = 1 + 3 + 5 + 7
52 = 1 + 3 + 5 + 7 + 9

Therefore, if you need to reduce your lookup table, you can interpolate a missing square using data present in the table, and your index:
x^2 = squares[x-1] + (x*2) - 1
or
x^2 = squares[x+1] - (x*2) - 1

The tradeoff obviously is some CPU cycles (not horrible since interpolating never requires more than 8 bits + carry), but you reduce a 512-byte LUT to 256 bytes.
Mikey
Posts: 9
Joined: Thu Jan 05, 2023 12:35 pm

Re: Modern Mapper Replacement Chips?

Post by Mikey »

(Also: it turns out that interrupts on all microcontrollers are basically strictly out of scope. They just have too much jitter and/or too much latency.)
Interesting... I knew that if the chip was sleeping and in low power mode, that yes, the wake-up interrupts would have a ton of latency and jitter.

But with the Cortex M4, I thought I'd read that it has a max of 16 cycles of latency (when it's already awake); but now that you've mentioned this I've done some more searching (specifically related to the STM32F4 part), and indeed people are experiencing 100ns+ latency and way more jitter... I wonder why there is such a big discrepancy.... -- That's nuts! -- If that's the case, yeah, I don't think interrupts would work at all.
the things that MMC5 does that are unique are needlessly crippled.
Interesting. -- Is there another way to achieve the 8x8 attributes with another known mapper that's not crippled?
The one that the software that you want to run uses.
Again, it's for my own software that I haven't written yet, but I really want to use those 8x8 attributes -- are there any other mappers that can do this?

I noticed that there are recognized homebrew mappers on the nesdev wiki -- there's just a lot of mappers on there though and I'm just not familiar with all of them; I've been digging but just haven't found anything decent yet. -- So recommendations or pointers would be nice on mapper selection.
... In the ballpark of 50 cycles or so?
I guess that's only about double the cycle count -- but with no mapper dependency that is still a win. So thanks for sharing this. That's really cool.
... and we later discover it's not - you've just stuck yourself in a square hole...
Interesting... so the thought is, it might work now... in both emulators and hardware -- but in the future if/when emulators get more compatible with MMC5... my code could stop working in those emulators... that's a good call out too. -- Annoying, but better than the alternative. -- Thanks for advocating against this, it helped me change my mind.
... you'll have to add the cost of voltage translation.
-- Yeah, I saw that when I was digging into it last night, super annoying. -- I will save FPGA learning for another day.


EDIT: moving this to last since it's kind of a side discussion -- but anyway: /EDIT
Unfortunately, you're wrong - timing is simply cumulative.

On the NES, you have roughly 350ns from when /ROMSEL goes low until final data for the CPU must be valid.

If you use an external ROM - for the sake of argument, let's say one with 110ns cycle time - that reduces your timeline by those same 110ns, so you have to get a completely valid address to the ROM after only 240ns.
In a traditional ASIC mapper design where /EN goes through the mapper chip, yes it's cumulative. Because every bus operation would need to propagate through the mapper chip before the memory device on the other side of it can respond. -- (i.e. the timeline of events is serial and hence cumulative; e.g. on the MMC3 /ROMSEL goes into the mapper, and comes out connecting to the ROM on PRG /CE -- and the mapper sits as a "man in the middle" that can decide to propagate the signal or not.)

It's the same for other lines (such as address lines and data lines), if they need to propagate through the mapper chip, then the timeline is serial, and the timing is cumulative.

But with an MCU Mapper we wouldn't need to design the circuit that way, instead we can connect the memory device on the same bus (almost*) in parallel with the MCU, so that propagation is unnecessary for normal bus operations; the MCU just has to leave it's bus lines tri-stated in high impedence mode and do nothing, and the memory device just does it's job -- i.e. /ROMSEL goes low, and the memory device gets enabled and responds while the MCU seemingly does nothing to aid or prevent this.

We could achieve this by taking /ROMSEL from the port and passing it into an OR gate with the other input being an output bit from one of the MCUs pins -- then we take the output of that OR gate and pass it into the PRG /CE (this sounds complicated, but an OR gate is just two diodes -- so /ROMSEL -->|-- PRG /CE and MCU IO PIN -->|-- PRG /CE -- if either is high, the memory chip is disabled, if they're both low, it's enabled).

So, as long as the MCU has that output bit set to 0, the memory device just works as is, and responds to bus requests as it should.

If the mcu needs to write a byte to the data bus (i.e. the if the program is reading from a mapper register), the MCU can set that output enable bit to 1 at the same time as it writes its byte to the data bus; and when it sets the data bits back to high impedence at the end of the operation, it can set that bit back to 0 at the same time.

Ideally, this should only add 20ns to the response timeline -- and only when the MCU needs to master the response byte.

*: Yes, some of the address lines are still multiplexed through the MCU; but they're not propagated in a way that would effect the timing; they change between bus operations (i.e. as a result of writing to a bank switching register), not during the operation. -- Hence the timing would not need to be cumulative.
Joe
Posts: 650
Joined: Mon Apr 01, 2013 11:17 pm

Re: Modern Mapper Replacement Chips?

Post by Joe »

Mikey wrote: Wed Jan 11, 2023 12:07 pm*: Yes, some of the address lines are still multiplexed through the MCU; but they're not propagated in a way that would effect the timing; they change between bus operations (i.e. as a result of writing to a bank switching register), not during the operation. -- Hence the timing would not need to be cumulative.
If you have more than one bank register, you need to select which one of those registers will drive the ROM's upper address lines according to the cartridge bus upper address lines, and those ROM address lines have to be driven quickly enough for the ROM to produce the correct data within the time limit.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Modern Mapper Replacement Chips?

Post by lidnariq »

Mikey wrote: Wed Jan 11, 2023 12:07 pm Interesting. -- Is there another way to achieve the 8x8 attributes with another known mapper that's not crippled?
The only other mappers that provide 8x8 attributes are FPGA mappers - one designed by Quietust for a port from an Amiga game, and one in development by twitter "SomethinNerdy" who said "wait, why bother with 8x8 attributes when we can have 8x1?"
I noticed that there are recognized homebrew mappers on the nesdev wiki -- there's just a lot of mappers on there though and I'm just not familiar with all of them; I've been digging but just haven't found anything decent yet. -- So recommendations or pointers would be nice on mapper selection.
My personal favorite is mapper 19. I think it's a very good mix of features, but it conspicuously doesn't have 8x8 attributes.

(Most of the win of 8x8 attributes is not making art easier. Neither 8x8 nor 16x16 attributes on 3-color tiles are particularly easier to work with. And modern tools like NAW and NEXXT make it easier for artists to intuitively understand the constraints of larger attribute zones and work with them, too.

(Instead, the win with 8x8 attributes is getting rid of the awful layout of the attribute table. Too bad one's still afflicted by the inconvenient layout of the nametable)
But with an MCU Mapper we wouldn't need to design the circuit that way, instead we can connect the memory device on the same bus (almost*) in parallel with the MCU, so that propagation is unnecessary for normal bus operations; the MCU just has to leave it's bus lines tri-stated in high impedence mode and do nothing, and the memory device just does it's job -- i.e. /ROMSEL goes low, and the memory device gets enabled and responds while the MCU seemingly does nothing to aid or prevent this.

[...]

So, as long as the MCU has that output bit set to 0, the memory device just works as is, and responds to bus requests as it should.
Ok, so you're just talking about what I've referred to on the wiki as "GNROM" or "32" banking - there's exactly one access window, and it's not a function of the CPU's address bus. That's not challenging at all, but it's also not particularly versatile.

Compare to GNROM (m66), UNROM (m2) and MMC1 (m1), and then contrast to MMC3 (m4), Namco's 163 (m19), and Sunsoft's FME-7 (m69).
Post Reply