nesdev.com

Then I need to figure out how to put games bigger than CNROM into a collection. My current idea is to take a bigger game designed for mapper 34 and then have the builder stick a table of relocated bank numbers at $FFE0-$FFEF of each bank to take into account where in the collection the game is loaded. Given the way bus conflict avoidance works in mappers like 2, 3, and 34, it might be crazy enough to work.

First off I wanted to let you know I tested this out on the NESDEV1 and it works great. I did have one funky thing that happened but not sure why. One time I started it up and the menu screen (not title though) was orange background vice black. I played LJ65 and everything was fine. I reset to play another game and everything looked normal with black background in the menu. Not sure if it was something funky that happened after I configured my CPLD for the first time or what but I couldn't recreate it. I assume it's a non-issue but I thought I'd bring it up.



By bigger than CNROM do you mean PRG, CHR or both? I don't quite follow what your idea is. Sounds like you're looking for PRG bankswitching of BNROM but CHR switching of CNROM at the same time? If you elaborate a little more I could help you come up with the hardware and test something on the NESDEV1 if you're interested.

The way it handles CNROM and the way I plan for it to handle BNROM are completely separate. Donkey Kong Classics is a well-known CNROM multicart. I've made a few CNROM multicarts specifically for this collection: MineShaft + Zap Ruder, Thwaite + Lawn Mower, and LJ65 + Concentration Room + Russian Roulette. These are added with one PRG bank and multiple CHR banks, and each game's entry in roms.cfg specifies which of the ROM's CHR banks to decompress into CHR RAM before the game starts running.

The solution I envision is for games that span multiple PRG banks. It would need zero special support from the mapper beyond existing support for oversize BNROM, unless we were to somehow add mirroring control to this mapper or move the PRG bank register down to $6000. A game would be made for mapper 34 and vertical mirroring, and it would switch PRG banks through a bank table like that seen in the listings here. The ROM builder would patch the bank table to change what PRG bank numbers get read and written.

In case the wiki page gets moved or something, here's the code:

The ROM builder might patch this to

And because the same byte gets read and written back, we relocate the program and avoid bus conflicts.

Well that sounds fine enough, you mentioning things being "crazy enough to work" I got the impression you were considering something more complex than that. So Really you're just making a BNROM within your 'big' BNROM master mapper.



So something like mapper 78 in the Holy diver flavor for mirroring? Is there something to be gained by moving to $6000 aside from preventing bus conflicts? If not it should be less hardware/logic to just pull PRG-ROM /CE high like ANROM does during writes.

Are options limited based on what Memblers designed up (and possibly already ordered?) If not it seems like it would be worth while to add the extra logic to allow the versatility. You could do the extended BNROM, selectable mirroring, and avoid bus conflicts with three chips. A single '377 octal FF and pair of '02 NAND gates. Selectable mirroring only needs 3-4 NAND gates depending if you want to use 1 or 2 of the FF's outputs, and the bus conflicts only requires an inverter and a NAND gate aka two NAND gates. If you really wanted to you could even do single screen mirroring by using 1 more (3 total) of the FF's outputs and (EDIT: two) of the the unused NAND gates for ANROM style mirroring.

That would still allow for 1MB of PRG with the 5 FF outputs left. Or 512KB PRG and get some CHR-RAM bankswitching action for no added cost assuming 16/32KB SRAM is cheaper than 8KB which it usually is.

I already have plenty of infrastructure in the menu program to work around bus conflicts. It's just that Memblers mentioned something about distinguishing writes to the mapper from writes to the flash memory so that a surface-mounted memory can be soldered first and programmed later once it's on the board.

I like that solution to that issue. Much better than a doing a mapper defeat with EXP0. It also comes with the added benefit of being able to store save data on the cartridge if desired.

Instead of 2 NANDs to prevent bus conflicts like I was discussing above, you need something to NAND 4 signals. Best way to do that is probably something like a 4068 (8 I/P NAND).

Then you could add in the single '02 if mapper selectable mirroring was desired.

Anyways, I'm sure it all works as you've got it planned, but my offer is still there if you'd like to test something. I've got flash onboard as well if you want to test any functionality there.

I guess the downside of all of this is there isn't any emulator support for this mapper currently. But that could also be considered a good thing I guess, the games are all available individually if people want to play on an emu. It may provide a little more incentive to buy the carts.

I doubt that all games using mappers with bus conflicts read the value from ROM before writing it back... Sometimes when I want to switch quickly to a constant bank I just write the bank number over the operand of the instruction that loaded the value. These would have to be hacked individually.

Even when I use a bankswitch table, I usually prefer saving 2 cycles by just transferring the bank index from one register to the other rather than loading the value from ROM.

Tepples,

In a few hours I will be setting up the homebrew exhibit at the MGC. I need the ROM image for Action 53. Please email it to me when you get a chance.

Then it'd just be a requirement for porting games to Action 53, just as vertical mirroring is a requirement.

clueless: These ROMs use a pre-0.03 menu engine and have the requested censorship applied to their config files (gambling game omitted from menu, Slappin' renamed).

• 4 Mbit version (includes Pogo Cats and NES15)
• 2 Mbit version (omits those games)

Bad news. Neither of those ROMs will play on my powerpak. My other ROMs load fine. When I tell the powerpak to load either of the action53 roms, the screen clears to black, but the game never boots up; the NES locks up.

You have an old version of mapper 34. The old version supports only 128 KiB, as I mentioned before; the new version supports all 512 KiB.

Do I need to put detection for this situation into the menu software?

Loopy's mappers solved my problem. Thank you.


Actually, detecting the problem and giving the user an error message would be useful. Can you detect that you are on a powerpak with older mappers from inside the NES?

It's easy to detect when upper banks aren't accessible. I wouldn't go through the trouble of doing this though. If you own a PowerPak, it's common sense to blame the mapper when a game doesn't run, so the first thing you should do is look for the most updated version.

Yeah, BNTest from the previous discussion was my method of proving out this limitation.


Especially because doing so would require putting part of the menu (the part that detects whether the last bank is reachable) in bank 0, 1, 2, or 3, space that could be used for another game in a pinch.

I guess you COULD put the mapper validation code with the menu in one of the lower banks (the part that tries to access upper banks would run from RAM), so that no more space would be needed in other banks, but I still think it's not worth the trouble.