Need help with mmc5.cpp source, for custom modification

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

infidelity
Posts: 340
Joined: Fri Mar 01, 2013 4:46 am

Re: Need help with mmc5.cpp source, for custom modification

Post by infidelity » Tue Nov 19, 2019 5:14 am

Hmm, MMC5Plus? Can now use 1024kb wram? Loving these new discoveries.

https://github.com/keyboardspecialist/MMC5Plus

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Need help with mmc5.cpp source, for custom modification

Post by tepples » Tue Nov 19, 2019 7:00 am

It strikes me as "fantasy console" until someone writes a mapper in Verilog to use on a PowerPak. So I filed the first issue:
Can we get an an implementation of this mapper in Verilog so that it'll run on a PowerPak? I'm aware that the PowerPak has only 544 KiB of RAM, but perhaps it could be made to work by using half of the 512 KiB of RAM that most mappers allocate to PRG ROM.

infidelity
Posts: 340
Joined: Fri Mar 01, 2013 4:46 am

Re: Need help with mmc5.cpp source, for custom modification

Post by infidelity » Tue Nov 19, 2019 7:17 am

Everdrive N8 Pro in 2020 will be perfect for the larger MMC5 titles, present & future.

kuja killer
Posts: 104
Joined: Mon May 25, 2009 2:20 pm

Re: Need help with mmc5.cpp source, for custom modification

Post by kuja killer » Tue Nov 19, 2019 8:24 am

What does this part mean exactly ??

".byte $0C ;256KB of CHRRAM"
and
"This mapper extends MMC5 to allow usage of CHR RAM"

It already had CHR RAM, at least you can only pick CHR-ROM or CHR-RAM ..not both.
So why is it saying that ?

I wish it was possible to use both chr-ram and rom at the same time. I could defintely make use of it for my game. just the "ram" part in a couple places, while the rest of the game is ROM.

But im not going to break the rules about being "emulator only". So cant/wont.

infidelity
Posts: 340
Joined: Fri Mar 01, 2013 4:46 am

Re: Need help with mmc5.cpp source, for custom modification

Post by infidelity » Tue Nov 19, 2019 8:34 am

I would love a register to enable both CHR-ROM/RAM. Maybe an FPGA MMC5 in the future with enhanced features?

calima
Posts: 1190
Joined: Tue Oct 06, 2015 10:16 am

Re: Need help with mmc5.cpp source, for custom modification

Post by calima » Tue Nov 19, 2019 11:59 am

kuja killer wrote:I wish it was possible to use both chr-ram and rom at the same time. I could defintely make use of it for my game. just the "ram" part in a couple places, while the rest of the game is ROM.
A common need, it seems ;)

As for the huge and extended MMC5, at that point it makes more sense to move to the Super NES IMHO.

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Need help with mmc5.cpp source, for custom modification

Post by tepples » Tue Nov 19, 2019 12:08 pm

Provided you can fill more than one layer and more than four colors per tile and upgrade the soundtrack to sampled sound.

I think some of these "wonder mapper" proposals are compensating for the TurboGrafx-16 (export version of the PC Engine) never becoming popular.

infidelity
Posts: 340
Joined: Fri Mar 01, 2013 4:46 am

Re: Need help with mmc5.cpp source, for custom modification

Post by infidelity » Tue Nov 19, 2019 2:42 pm

I just love the NES so much, it's my favorite console, and I've loved coding for that machine, I especially love the work I've done with Legend of Link & Super Mario All-Stars NES (both MMC5 projects) and my next MMC5 project really has me excited, which is why I'm very happy the wram for the MMC5 can go as high as we found out.

Regarding moving onto the SNES, due to the MMC5 rivaling to a degree, I've been wanting to for years, but the developer for the bsnes debugger has refused to make the upgrades I've requested for years, yes years, in how the logging performs & looks through the hex Viewer. FCEUX has been my sole method of rom hacking since 2004. Some write out the language, I write via hex. And if the quality of the bsnes debugger matched my small requests, then I'd jump ship to the SNES.

I already have projects in mind for the SNES, especially with MSU-1, but sadly it's all dependent on bsnes debugger getting g the small upgrades. And I'm not alone in this department for hoping to get these upgrades to the debugger.
Last edited by infidelity on Tue Nov 19, 2019 2:46 pm, edited 1 time in total.

tepples
Posts: 22054
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Need help with mmc5.cpp source, for custom modification

Post by tepples » Tue Nov 19, 2019 2:44 pm

I'm curious about what you think of the Mesen and Mesen-S debuggers.

infidelity
Posts: 340
Joined: Fri Mar 01, 2013 4:46 am

Re: Need help with mmc5.cpp source, for custom modification

Post by infidelity » Tue Nov 19, 2019 2:50 pm

tepples wrote:I'm curious about what you think of the Mesen and Mesen-S debuggers.
I heard Mesen was incredibly accurate to a real NES. But other than that that's all I've ever known of it.

User avatar
rainwarrior
Posts: 7841
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Need help with mmc5.cpp source, for custom modification

Post by rainwarrior » Tue Nov 19, 2019 4:20 pm

infidelity wrote:Hmm, MMC5Plus? Can now use 1024kb wram? Loving these new discoveries.
https://github.com/keyboardspecialist/MMC5Plus
From the description I don't really understand how this is a new iNES mapper? The ability to specify large CHR-RAM and PRG-RAM already require iNES 2, and that fully satisfies the specification needs.

It would need a new mapper chip, of course, with 1-3 more bits of PRG-RAM bank state if you want to go beyond 128k, but that doesn't have much to do with the iNES mapper. Its emulation would be defined the same either way, wouldn't it?

Really the question is just what an emulator author decides to do with the iNES 2 CHR-RAM and PRG-RAM fields for this mapper.

Edit: oh, now I see the difference. They want CHR-ROM and CHR-RAM at the same time? Well, that's a new thought to me. I don't really care about that idea, though. I'll let someone else make the case for it. :P Also realizing this thing is 6 years old...


There are 4 PRG-RAM configurations that are definitely worth caring about, if you wanna emulate those Koei games: 0k, 8k, 16k, 32k

Some things support 64k already, but mostly because it was a convenient compatible superset of the existing arrangements.

You can't expect an emulator to support anything else than this at this point, but at the same time there's really nothing ambiguous about the bankswitching register interface. So...3 bits are definitely spoken for, a 4th bit for 128k is possible on the chip (but academic, as there was never a board or a game for it), and 3 more bits aren't assigned to anything and would be perfectly symmetrical to other bank registers if they bankswitched PRG-RAM.


So, once iNES 2 support was implemented for this mapper, I didn't really see any extra workload to support 7-bit vs 4-bit or 3-bit, at least not the way I implemented it... No reason not to just let it be 7, at least provisionally. This is just "undefined behaviour" territory where for the most part it shouldn't matter.

Whether making use of those bits is "valid" is a different question, but if you don't think it's valid, you aren't ever going to use those 3 extra bits anyway. It's one thing when people ask for fantasy features that require significant real implementation work and have no plausible current use, but with iNES 2 support already being an established and valid need, there seemed to be no significant additional support work to do for the 1MB extension.

If someone comes up with a good use for it and makes a cool thing people want to emulate, maybe then you'd have a shot at seeing more widespread emulator support, but for the time being provisional support in FCEUX seems harmless to me? At this level it's just a curiosity interested developers might play with, and everyone else can ignore. Similarly, I'd also be opposed to documenting this as a normal capability of iNES mapper 5 on the wiki. It's not "real" in this form, just a hypothetical toy.


Though, that does get me to an ulterior motive. Say I want to make a future project that lets people create stuff, e.g. level editor, mario paint, music composer, etc. There are really only two mappers which had common large PRG-RAM support: MMC1 and MMC5. MMC1 / iNES mapper 1 is a horribly confused mapper, and the big PRG-RAM it does support is already strained to its breaking point. MMC5's large PRG-RAM on the other hand is straightforward and has this perfectly natural possible extension. It's about as ideal as it could get for this purpose.

After that, the next best candidate would maybe be FME7, but there was never a board with more than 8k. The rest tend to be obscure/multicart things.

tepples wrote:Can we get an an implementation of this mapper in Verilog so that it'll run on a PowerPak? I'm aware that the PowerPak has only 544 KiB of RAM, but perhaps it could be made to work by using half of the 512 KiB of RAM that most mappers allocate to PRG ROM.
Yes, it does seem that hypothetically 256k PRG-ROM + 256k PRG-RAM could be accomodated on either PowerPak or Everdrive.

lidnariq
Posts: 9688
Joined: Sun Apr 13, 2008 11:12 am
Location: Seattle

Re: Need help with mmc5.cpp source, for custom modification

Post by lidnariq » Tue Nov 19, 2019 5:04 pm

kuja killer wrote:I wish it was possible to use both chr-ram and rom at the same time. I could defintely make use of it for my game. just the "ram" part in a couple places, while the rest of the game is ROM.
There's genuinely no advantage to mixed CHR RAM+ROM any more, unless you are limited by PRG capacity. (Back in the commercial era, large SRAMs would have been prohibitively expensive, but that's not really a factor anymore) Otherwise you're better off with just RAM and storing the graphics compressed instead. All mappers that support bankswitching of CHR have no difficulty with that regardless of whether it's ROM or RAM, so there's no feature loss here.

I'm explicitly disqualifying "convenience" as a reason: any game complex enough to have enough graphics to benefit from having both types of graphics memory is necessarily large enough in scope that the incremental benefit of "not having to upload fixed tiles to some of RAM" is minuscule in comparison.

kuja killer
Posts: 104
Joined: Mon May 25, 2009 2:20 pm

Re: Need help with mmc5.cpp source, for custom modification

Post by kuja killer » Tue Nov 19, 2019 6:13 pm

I see, lidnariq - well i mentioned it cause, i thought it would maybe be possible for 1 example to to use some code to do parallax scrolling of graphics without needing 16 to 32 copies of the graphics that would be parallax'd.

Ya know how like if you wanna do it to the entire screen without affecting anything else on screen, like anything can be in the way no matter how high or low, ...the kind where you DONT use IRQ's... but instead need a copy of the graphics shifted right/left 1 pixel every time ?? It takes up tons and tons of graphic space.

The NES game, Metal Storm - off the top of my head.

i thought like you could do something to just 1 copy...AND, or ORA or...XOR i have no idea -- to shift it all 1 pixel at a time, with the CHR-RAM. so you dont need those 30+ copies.

I tried it once, but i just didnt know how to write the code.
Last edited by kuja killer on Tue Nov 19, 2019 6:24 pm, edited 1 time in total.

User avatar
rainwarrior
Posts: 7841
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Need help with mmc5.cpp source, for custom modification

Post by rainwarrior » Tue Nov 19, 2019 6:21 pm

You get that ability just with large CHR-RAM. There's no need for CHR-ROM as well for that case.

Sour
Posts: 815
Joined: Sun Feb 07, 2016 6:16 pm

Re: Need help with mmc5.cpp source, for custom modification

Post by Sour » Tue Nov 19, 2019 8:48 pm

infidelity wrote:I heard Mesen was incredibly accurate to a real NES. But other than that that's all I've ever known of it.
In case you want to take a look, the documentation for Mesen's debug tools are mostly up to date and should give you a decent idea what it looks like.

Post Reply