O.k. i keep getting a >$1FFF error in NESASM.exe. after looking at Hex Editor it seem i have passed the 8kb Mark on my demo. So now i have to start using mappers. Im gonna start using the MMC1, but had a few questions on it.
1. When using the mapper do it write a new bank of code (.org $E000) above the NMI routine right under my $8000 bank.
2. What is this mean?
¦ ¦ ¦+------PRG Switching Size
¦ ¦ ¦ 0 = Swap 32K of ROM at $8000
¦ ¦ ¦ 1 = Swap 16K of ROM based on bit 2
-courtesy Comprehensive Map. Doc. ; MMC 1
3. Since ill be switching to the next bank in my demo. writing to these must done in nmi and with flag to swap back if i need to. Right?
4. i read somewhere that in this mapper reg 0 and 3 are used for the PRG
while 1-2 are for CHR. Is that true. Should i use Reg 3 ($E000 - $FFFF) for my new bank to swap when needed?
any help would rock thanks in advance.
el
You should be able to address up to 32k of ROM before needing a different mapper besides the simple NROM.
The NESASM directive to declare two 16k areas of PRG ROM is:
Code:
.inesprg 2 ; 2x 16KB PRG code
Then you can define the banks like so:
Code:
.bank 0
.org $8000
.bank 1
.org $A000
.bank 2
.org $C000
.bank 3
.org $E000
Sounds like you may just be going over the boundary from the $8000 8k bank to the $A000 bank. I think NESASM is just trying to squish it all into the 1 bank where you could actually just relocate some subroutines into the next bank (bank 1) and jump to them there.
ok its worked but on wierd conditions. this how my lay out was:
Code:
inesprg 1 ;only worked when set to 1
.bank 0
.org $8000
-----code------
.bank 1 ;only worked when set to 1
.org $a000
-----code------
.bank 1 ; set the following to 2 and 3 respectively with no luck
.org $FFFA
.dw 0 ;(NMI_Routine)
.dw Start ;(Reset_Routine)
.dw 0 ;(IRQ_Routine)
.bank 2
.org $0000
.incbin "graphics.chr"
it only works on this layout any other layout like to ones ive tried yields a grey screen. where do i put my ny new bank?
In an NROM-256, inesprg is 2 (four banks), vectors must be in bank 3, and CHR must be in bank 4.
And I should mention that there are better mappers to use than MMC1. I personally think MMC1 is overcomplicated. It'd be alot easier/better to use MMC3. Or you could more easily use a board like UxROM.
MottZilla wrote:
I personally think MMC1 is overcomplicated. It'd be alot easier/better to use MMC3. Or you could more easily use a board like UxROM.
But for the lack of SRAM, I'd be using UNROM in my own project. And I'm sure that a lot of SNROM games might have been UNROM for the same reason, especially those that needed to save things.
No doubt. But if you need WRAM, why not just use MMC3? It can't just be me that thinks MMC1 is annoying compared to the simplicity of MMC3.
What's so complicated about MMC1? The shifting? The only problem I see with it is that it uses a lot of cycles, but MMC3 also wastes some with a command register.
i wanted to use the mmc1 cause i found that the i could find SAROM cheaper and more common. something with WRAM. but if could figure out how to bypass the mapper situation with discrete logic im all for it. but im still looking in to it. i wonder if you can use SRAM instead of WRAM as a battery backable memory source. no WRAM's on jameco. thats for sure. as my demo contiues along i found that i that i running out of page space as well and would be in need of some spare RAM. 7 pages just isnt enough. any soultions?
WRAM is just "work RAM". That's just an NES-specific term for an 8 KiB SRAM decoded to $6000-$7FFF. Someone else here claims that this decoding can be done with one or two 7400 chips, but I'm waiting for him to post detailed instructions here or on the wiki.
kyuusaku wrote:
What's so complicated about MMC1? The shifting? The only problem I see with it is that it uses a lot of cycles, but MMC3 also wastes some with a command register.
Pretty much and I agree on MMC3. If only the MMC3 didn't have a command register, and didn't have the retarded setup of 2 2K banks and 4 1K Banks. I mean seriously would it have killed them to make it 8 1k banks?
Mainly I don't like the MMC1's Shift register issue. Takes more cycles than I'd like, and more bytes of space than I'd like. If you're going to develop a game now, why limit yourself? Why not use the best thing you can get? Well, atleast something better than MMC1. I wouldn't advise scrapping MMC5 games unless you're going to make the most badass NES game to ever be created. :p
sweet. you think its possible to use more than 8kb of memory. i lookin for about a least 8 times this space. would it be possible to link a 64k SRAM to the addressing pins of my PRG ROM and just transfer about less then for 4KB at a time to each bank at a a time (ie. $1000,$2000,$3000,ets.... ) to the SRAM using the OE CE and WE to bypass a write to the PRG ROM.
i thinking its possible using all A0-15 pins of PRG ROM. i mean the WRAM on the MMC1 is tied to the addressing lines on the PRMROM and the NES. so why not just tie them all and not just ones that decode 6000-7FFFF?
MottZilla wrote:
If only the MMC3 didn't have a command register
Then it would have had more pins, and it would have taken more space on the board. Pins are one of the most expensive parts of a semiconductor package.
MottZilla wrote:
If you're going to develop a game now, why limit yourself? Why not use the best thing you can get? Well, atleast something better than MMC1.
MMC1 is the best thing you can reasonably get without sacrificing donor carts. If you are just targeting emulators and maybe a couple repros instead of a full new game release, you could look at the VRC series. Most (all?) of them use 1KB chr rom banks, have 8KB prg banks, irq, etc. The FME7 chips also have similar specs without the different sized chr banks of the MMC3.
So far MMC1 is even overkill for my game ideas. UNROM seems to be my mapper of choice for size and manufacturing.
MottZilla wrote:
Mainly I don't like the MMC1's Shift register issue. Takes more cycles than I'd like, and more bytes of space than I'd like.
I agree that it's a bit awkward, but the overhead it's not really noticeable unless you've got code and data stashed all over the place and need to swap in every other function. The benefits of MMC3's finer bank-switching granularity and raster IRQs are *far* larger, but if you don't need them then I'd go for the minimalistic setup whenever possible.
Actually I've sped up my own MMC1 switching a bit by relying on the dummy writes of the RMW instructions. That is INC/DEC/ASL/LSR (and some of the illegals) first rewrite their original value before writing the new one which can be exploited by placing some strategic constants in the $E000-$FFFF range and working on it with the right instruction. The big drawback is that you can only write an even number of bits this way and the shift register needs to be fed five. If you can design your code to place two switches in a row then you can write six bits the first time around, thus latching in the first bit of the next bank as well, and only the last four the second time.
Code:
asl c00 ;; write %00
dec c03 ;; write %01
inc c00 ;; write %10
lsr c03 ;; write %11
*= $e000
c00 .byte %00000000
c03 .byte %00000011
This amounts to 18 cycles per switch with a LDA #/STA pair for the final bit, or 15 cycles on average if you can combine two switches. Naturally you'd want hide away this entire mess into some nice macros in any case.
I always had two paticular beefs with MMC3:
1) No 1-screen mirroring (seriously, wtf)
2) restrictive and coarse scanline counter instead of a flexible, fine-tune, and unrestrictive CPU cycle counter.
When you compare MMC3 to any one of the several 2nd party mappers which have similar functionality (VRC4, FME7, VRC6, whatever mapper 18 is), they all pretty much leave MMC3 completely in the dust in terms of functionality (even if they are a bit more weird to use). Just kind of seems pathetic to me that MMC3 was the worst option in its class.
I still like MMC3 over MMC1, though, if only because it has an IRQ counter. MMC3's lack of 1-screen still makes MMC1 have some function, though.
Of course... if they would have just PUT decent IRQ functionality on the NES from the get-go instead of putting it into mappers, most of this would be a non-issue. I still don't understand why they put APU Frame IRQ functionality in, but decided not to make Sprite-0 hit generate an IRQ. durrrrr. They even had the presence of mind to put a CPU cycle counter on the FDS and that wasn't released too long after the FC was. I guess they realized that they made a huge blunder pretty quick.
EDIT
Just read your post in more detail doynax. That trick shouldn't work! Writes that are too close together (ie, consecutive cycles) are too quick for the MMC1 to respond. A game which relies on this behavior is Bill & Ted's Excellent Video Game Adventure. The game does "INC $FFFF" where $FFFF=FF to reset the mapper (since this writes FF, then 00). However, the 00 write goes ignored as if it never happened. I would figure the same thing would happen with your trick -- only the first of the two writes would actually happen, and the second would be dropped.
Did you try this trick on an actual board? (read: PowerPak doesn't count). I don't see how it would work unless there's something about the reset bit that makes it take longer to respond... or unless there's different MMC1 versions. Either way, I'd highly recommend you don't use this trick.
Quote:
Writes that are too close together (ie, consecutive cycles) are too quick for the MMC1 to respond. A game which relies on this behavior is Bill & Ted's Excellent Video Game Adventure. The game does "INC $FFFF" where $FFFF=FF to reset the mapper (since this writes FF, then 00). However, the 00 write goes ignored as if it never happened. I would figure the same thing would happen with your trick -- only the first of the two writes would actually happen, and the second would be dropped.
Well, technically the MMC1 takes writes according to the status of the adress/control bus regardless of how many instruction it took to write. Maybe it's the reset signal that makes it not accept writes for a few cycles ? Anyway, like you said, this should be tested on hardware.
Quote:
I always had two paticular beefs with MMC3:
1) No 1-screen mirroring (seriously, wtf)
2) restrictive and coarse scanline counter instead of a flexible, fine-tune, and unrestrictive CPU cycle counter.
I couldn't agree more, altrough 1-screen mirroring can be possible my chaging mapper from 4 to 118 by then you're limited in your CHRROM bank switches if you use all available 256 KB.
Quote:
Of course... if they would have just PUT decent IRQ functionality on the NES from the get-go instead of putting it into mappers, most of this would be a non-issue. I still don't understand why they put APU Frame IRQ functionality in, but decided not to make Sprite-0 hit generate an IRQ. durrrrr. They even had the presence of mind to put a CPU cycle counter on the FDS and that wasn't released too long after the FC was. I guess they realized that they made a huge blunder pretty quick.
Yeah, replaceing sprite-zero hit and all that crap by a reliable PPU driven interupt source would be much better (like the SNES and most other console does). However, the good side of this is that it give us fun headaches how to do tricky raster effects, that would be too easy to do otherwise.
Disch wrote:
Just read your post in more detail doynax. That trick shouldn't work! Writes that are too close together (ie, consecutive cycles) are too quick for the MMC1 to respond. A game which relies on this behavior is Bill & Ted's Excellent Video Game Adventure. The game does "INC $FFFF" where $FFFF=FF to reset the mapper (since this writes FF, then 00). However, the 00 write goes ignored as if it never happened. I would figure the same thing would happen with your trick -- only the first of the two writes would actually happen, and the second would be dropped.
Did you try this trick on an actual board? (read: PowerPak doesn't count). I don't see how it would work unless there's something about the reset bit that makes it take longer to respond... or unless there's different MMC1 versions. Either way, I'd highly recommend you don't use this trick.
Dammit.. No I don't have anything resembling proper hardware to test on.
Then how long do I have to wait between writes to be safe?
Personally, I don't like the MMC1 because:
1. the way the registers are written to is weird and slow;
2. 4KB CHR-ROM switching is not good for gaphically complex games;
So I feel that it works much better with CHR-RAM, but then there really isn't an advantage over using UOROM (except for the 32KB PRG switching, which I don't think is very useful anyway), which is simplicity at it's best.
My problems with the MMC3 are:
1. the scanline counter is very limiting, in a sense that in order to use it you must give up on using native features of the system;
2. the way in which the pattern table is divided, they really should have gone for 8 1KB chunks;
In the end, difficulty of reproducing carts aside, I'd rather use the MMC3. The possibility of switching 2 8KB PRG-ROM banks is really necessary in games with a lot of data. The CHR switching is good enough for most games, even if you have some redundancy of tiles.
Usually my game designs involve the use of 8x16 sprites fetched from both sides of the pattern table, so I really do hate it's scanline counter with all my guts. In my current project, I'm only using the scanline counter to hide scrolling glitches by the top of the screen, but as soon as the IRQ fires I start breaking the MMC3 rules.
Quote:
So I feel that it works much better with CHR-RAM, but then there really isn't an advantage over using UOROM (except for the 32KB PRG switching, which I don't think is very useful anyway), which is simplicity at it's best.
The advantage is the official support of SRAM (altrough mapper 2 can also have SRAM there is no official cartridge with it), and the ability to switch between 4 different mirroring modes, which is great and the MMC3 cannot do unless you wire it differently as in mapper 108.
Quote:
2. 4KB CHR-ROM switching is not good for gaphically complex games;
I don't know what you mean by "graphically complex". 4 KB switching worked wonder for a couple of games like Double Dragon or Fire Emblem, and should work fine in most games, while I'll admit it can be bothersome to mirror the hero sprite and textbox tiles in all sprite and BG banks respectively.
tokumaru wrote:
So I feel that [the MMC1] works much better with CHR-RAM, but then there really isn't an advantage over using UOROM (except for the 32KB PRG switching, which I don't think is very useful anyway)
The advantages of SNROM over UOROM are 1. PRG RAM, and 2. battery-backed PRG RAM. Not all games that last longer than a half hour can serialize their state to a 16-character string.
We just need someone to clone the MMC5 and put it all to rest with new MMC5 boards. :p at first I thought the MMC5 was crazy, but after working on adding partial emulation of it for my emulator to run CV3, I realized the MMC5 is quite nice. Has the scanline counter that actually works, has the ability to swap in all sorts of ways. Even has the ability for you to have 8KB of Sprites instead of 4K. You can get that extra name table, you can do OneScreen mirroring... there's nothing I can think of that you can't do...
MMC5 I think would even be useful for making a hacked FDS Bios to run FDS games since you can map up to 64K of WRAM in any bank but the last one. I think you could make a hacked FDS bios and just bank ROM in an available (not being loaded) window and load PRG-RAM and then bank back to all WRAM banks for 6000 - DFFF.
All the thinking about MMC5 makes me wish the PowerPAK had MMC5 support now. ='(
Do you think there is any hope that someone might either clone or make their own MMC3 level mapper for repro/new boards like the MMC1 has? While a MMC3 clone would be nice for building games that use it, just a mapper that is similar for homebrew would be sweet. 8K PRG banks, 1K CHR banks, working IRQ scanline counter and support for PRG-RAM. I'd think the hardest part is implementing the scanline counter. Can't be too hard to do this since the PowerPAK FPGA was configured to do it.
MottZilla wrote:
We just need someone to clone the MMC5
But it will take a FPGA (nonvolitile/static such as what's used in modchips) to synthesize MMC5 (since Mask ASIC are out of the question). Do you think a homebrew MMC5 is worth the $10 or so more than the cost of a CPLD? Personally I don't.
MottZilla wrote:
I realized the MMC5 is quite nice. Has the scanline counter that actually works
How is the scanline counter any different than a MMC3s? I assumed it worked on the same A12 counting principle, unless it counts Phi2 cycles and is triggered on filtered A12 to allow more flexible setup.
MottZilla wrote:
there's nothing I can think of that you can't do...
But it comes at a high cost, both to the board maker and customer (and think of all the wasted logic for vastly underused functions)
MottZilla wrote:
Do you think there is any hope that someone might either clone or make their own MMC3 level mapper for repro/new boards like the MMC1 has?
Not really because of the flip flop requirement, MMC3 can fit only into the largest 95th percentile of CPLD, much less better mappers which have full 1K CHR switching and a Phi2 counter.
MottZilla wrote:
While a MMC3 clone would be nice for building games that use it, just a mapper that is similar for homebrew would be sweet. 8K PRG banks, 1K CHR banks, working IRQ scanline counter and support for PRG-RAM. I'd think the hardest part is implementing the scanline counter. Can't be too hard to do this since the PowerPAK FPGA was configured to do it.
Well the PowerPak is having lots of trouble with the scanline counter probably because the proper logic doesn't work right for some reason. Artoh's FunkyFlash MMC3 however works great using a CPLD, but you'll have to find an EXTREMELY expensive CPLD to fit full 1K switching, which brings us back to using a static FPGA. The best compromise I think would be to use a common smaller CPLD as well as 4x74670 (4x4 bit registers) to form the 8x8 register ;)
Quote:
How is the scanline counter any different than a MMC3s? I assumed it worked on the same A12 counting principle, unless it counts Phi2 cycles and is triggered on filtered A12 to allow more flexible setup.
from a programmers point of view,
mmc3: the irq is fired relative to the current scanline
mmc5: the value written is the actual scanline#
the whole relative thing is only if you have multiple irqs per frame or setting up an irq mid-frame, otherwise you don't need to worry about it. the mmc3 just forces you to think a little more.
not sure about the hardware differences tough.
kyuusaku wrote:
How is the scanline counter any different than a MMC3s? I assumed it worked on the same A12 counting principle, unless it counts Phi2 cycles and is triggered on filtered A12 to allow more flexible setup.
I can't say with 100% certainty, but I really don't see how watching A12 would work. Keep in mind the MMC5 syncs with the PPU in other ways besides scanline counting (splitting the screen requires it to know
specifically which tile is being fetched... something A12 gives no indication of). Plus, watching A12 would fail utterly if BG and sprites both use the same side of the nametable -- something I'm quite sure MMC5's scanline counter is quite capable of (unlike MMC3).
I find it much more likely that it watches A13 to know when tile fetches occur, and syncs to the scanline some other way.
The big difference from a nesdever standpoint is that MMC3 limits your sprite CHR usage -- sprites can only use 256 tiles if you want the scanline counter to work. But on MMC5 you can use all 512.
kyuusaku wrote:
Do you think a homebrew MMC5 is worth the $10 or so more than the cost of a CPLD? Personally I don't.
Can't say that without seeing the MMC5 game first. We have yet to see such a complex homebrew that requires the features of the MMC5, but if it does happen, it will probably be a good game. Nobody would be crazy enough to make a crappy game for the MMC5 just for the heck of it. The person who does it will probably know what they are doing.
tokumaru wrote:
Nobody would be crazy enough to make a crappy game for the MMC5 just for the heck of it.
Tell that to Koei. They made about a dozen of them.
Ok, little clarification. When I end a statement with :p that means I'm not dead serious.
It certainly would be nice if MMC5 was a viable option for whatever you want to make. But in all seriousness, It would be nice if someone could come with an affordable MMC3 level mapper for homebrew/reproductions with mapper conversions.
MMC1 certainly is nice to have, but it also would be nice to have eight 1K section CHR swapping, three 8K PRG banks swappable + 1 fixed, and a decent scanline counter. I was just saying it would be a dream if you could use MMC5. But having something on the MMC3 level would be nice. The features I mentioned could be used by about any game that exceeds what you can do with MMC1.
I'd find it great if someone in the "scene" (bunnyboy?) created this new mapper, with 1KB CHR switching, 8KB PRG switching and a reliable scanline (cycle?) counter. Oh, and nametable layout selection. I'd love this mapper, and would use it for all my projects.
The problem is that since no game exists for this mapper, there is no incentive to create it. At the same time, if a mapper doesn't exist, nobody is going to program games for it.
Maybe the best shot would be to implement this "standard homebrew mapper" into the current emulators (after all features have been discussed here), and hack commercial games to work with it. It's features should accommodate most existing games without problems. With these games converted, there would be an interest making repros of them, and then there is a demand for a hardware implementation.
This could mean the end of the dependency of homebrewers on commercial carts, that will only get more scarce with time. I'm using the MMC3 for my game, but I'm not using the scanline counter for water effects, because I'm breaking all the rules. Instead I have special palettes to use underwater, which is very restrictive. I'm sure the game would look awesome with raster effects, but I'm not doing any because of the crappy scanline counter.
Quote:
I'd find it great if someone in the "scene" (bunnyboy?) created this new mapper, with 1KB CHR switching, 8KB PRG switching and a reliable scanline (cycle?) counter. Oh, and nametable layout selection. I'd love this mapper, and would use it for all my projects.
What you describe furiously reminds me the MMC5.
Also, remember that a game is something else than its mapper. People here seem to only talk about mappers and all, but you can do a decent amount of raster effect with mapper 0 without much problem, it just is a little harder. In fact a scanline IRQ counter only make things easier for the programmer, but it doesn't allow the impossible..
Quote:
Can't say that without seeing the MMC5 game first. We have yet to see such a complex homebrew that requires the features of the MMC5, but if it does happen, it will probably be a good game. Nobody would be crazy enough to make a crappy game for the MMC5 just for the heck of it. The person who does it will probably know what they are doing.
I was going to make a MMC5 RPG back then but I moved to a smaller project to increase my chances of success. Once it's done I'll do a RPG for sure but I don't know if I will do it on MMC5 as planned or if I'll move to a simpler mapper. It depends if I want to sell the game or not, currently I don't know much about selling NES game so I don't care for this, but in the future this may change.
Bregalad wrote:
What you describe furiously reminds me the MMC5.
Yeah, but without the terribly complex PPU features (extended attributes, increased number of BKG tiles and SPR tiles). What I described might be possible to implement without much cost.
Quote:
Also, remember that a game is something else than its mapper.
Of course, great games were made with simple or no mapper hardware in the past.
Quote:
People here seem to only talk about mappers and all, but you can do a decent amount of raster effect with mapper 0 without much problem, it just is a little harder.
I don't know, I'd say it's imossible to make a water effect like that in the Sonic games without a scanline counter. Even if you menaged to set up a sprite 0 hit, you'd have to waste a lot of time waiting for it to happen, something that would slow the hell out of the game. If only Nintendo had decided to generate an IRQ on sprite 0 hits (like someone said), that would already help a lot.
Quote:
In fact a scanline IRQ counter only make things easier for the programmer, but it doesn't allow the impossible..
It allows for interesting graphical effects without the need to sacrifice other aspects of your game.
Quote:
I was going to make a MMC5 RPG back then but I moved to a smaller project to increase my chances of success. Once it's done I'll do a RPG for sure but I don't know if I will do it on MMC5 as planned or if I'll move to a simpler mapper. It depends if I want to sell the game or not, currently I don't know much about selling NES game so I don't care for this, but in the future this may change.
I once thought about using it too, but I ended up giving up on a few things, and settled for the MMC3. The background will not be as detailed as I'd like, and the sprites will not have as much animation, but it's still all good. The MMC5 is much more than a mapper, it is able to modify the console in so many ways, like in an attempt to make it less outdated.
Quote:
Yeah, but without the terribly complex PPU features (extended attributes, increased number of BKG tiles and SPR tiles). What I described might be possible to implement without much cost.
Well, then if you're experienced at programming CPLD/FPGA stuff (I'm not) you could implement a simpler MMC5 that is "compatible" with the real one, but that only allow scanline counter, multiply and PRG/CHR switches, but that lacks ExRAM ($5104 would always be $00) and that ignores special nametable modes ($5015 would be ANDed with $55), and also obviously lacks sound.
You could also most likely run Castlevania III on such a mapper, since it doesn't use those features of the MMC5.
I'm pretty sure that such a mapper would be able to emulate 99% of existing commercial games if they were proprely hacked to init the mapper proprely at reset, to have compatible IRQs and to adapt the timing on games that relies on timed mapper writes.
If anyone is doing that, I'd then highly unrecommand relying on writes to registers that are implemented in the real MMC5 but unimplemented on this mini-MMC5 to not be taken, alse we'd end up with the same crap that already exists with the real MMC3 and the N109 that acts as a mini-MMC3.
Bregalad wrote:
You could also most likely run Castlevania III on such a mapper, since it doesn't use those features of the MMC5.
Castlevania 3 (and I'm pretty sure all commercial MMC5 games that don't use extended attributes) uses the "12K CHR swapped in at once" trick MMC5 does which involves the mapper seperating which CHR fetches are for BG and which are for sprites (and using different CHR regs appropriately) -- and if you're going that far, ExRAM and extended attributes probably isn't much more work. I'd imagine seperating BG fetches from Sprite fetches is the hardest part.
Quote:
I'm pretty sure that such a mapper would be able to emulate 99% of existing commercial games if they were proprely hacked to init the mapper proprely at reset, to have compatible IRQs and to adapt the timing on games that relies on timed mapper writes.
I don't really see the point in hacking existing games to use a theoretical mapper (or even a real mapper, for that matter). This kind of talk makes me think of the FFE mapper hack fiasco.
I guess if you're talking about for ease of putting on a cart... but isn't that what the PowerPak is for?
I actually wish I knew how to do this stuff. I can't imagine that designing such a cart would be difficult... but it'd probably be expensive to build.
tokumaru wrote:
I'd find it great if someone in the "scene" (bunnyboy?) created this new mapper, with 1KB CHR switching, 8KB PRG switching and a reliable scanline (cycle?) counter. Oh, and nametable layout selection. I'd love this mapper, and would use it for all my projects.
The closest mapper to this would be Sunsoft's
FME-7. It doesn't allow 8KB switching for the last PRG bank, though - but it allows ROM to be mapped to CPU $6000-$7FFF, something even MMC5 can't do. Specifically, IRQs are triggered by CPU cycles instead of scanlines. FME-7 appears to be supported by the PowerPak (it's marked good on the mapper table on the
PowerPak website).
And in addition to using extended CHR banks (for the new 2nd Quest enemies), Castlevania III uses ExRAM as an extra nametable for the flooding water during stage 6B (the sunken city stage). Akumajou Densetsu switches to horizontal mirroring (from vertical) when there's the flooding water, and clips the left side - including the status bar, which was stupid because it blanks out letters of the status bar (i.e. PLAYER becomes LAYER, SCORE becomes CORE, ENEMY becomes NEMY). Konami took advantage of MMC5's ExRAM and managed to preserve the vertical mirroring and status bar during the flooding scenes.
I did a couple mapper conversions to FME-7 and the mapper does seem quite nice. But that's again what I was talking about, a MMC3 level mapper. As it's already been said the MMC3 is like bottom of the barrel of MMC3 level mappers. Things like VRC4, FME-7, maybe Namco 106 don't have the limitations that MMC3 has. Gradius 2 was a great example of why the MMC3 sucks for its scanline counter that won't allow you to use sprites from the BG pattern table side. Yet obviously the VRC4 could do that.
I think that there would be people interested in a new mapper with MMC3 level features. Even if it is just a clone of the MMC3, though because better than MMC3 would be nice. I guess just in general we can all dream up some nice features for new mappers.
One thing I had a thought about was if you have your mapper registers between $4020 and $4FFF, then you could map something to $5000 - $5FFF. More memory space is always handy. You could put extra RAM or even have a ROM swap bank there. Generally the space is just wasted. I'm sure there's some technical reason behind it.
Quote:
And in addition to using extended CHR banks (for the new 2nd Quest enemies), Castlevania III uses ExRAM as an extra nametable for the flooding water during stage 6B (the sunken city stage). Akumajou Densetsu switches to horizontal mirroring (from vertical) when there's the flooding water, and clips the left side - including the status bar, which was stupid because it blanks out letters of the status bar (i.e. PLAYER becomes LAYER, SCORE becomes CORE, ENEMY becomes NEMY). Konami took advantage of MMC5's ExRAM and managed to preserve the vertical mirroring and status bar during the flooding scenes.
Yeah, I remember that now that you mention it. That's the only place the game use EXRAM it seems.
Also, on a real TV I'm often unable to see the 'S' of Score even if it's not technically clipped, because it's hidden by the topright corner.