In this post about an NES port of a spiritual sequel to an Action 52 game, thefox wrote:

not sure if I can fit the game in NROM though (not really interested in trying to optimize it for just that reason).

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.

tepples wrote:

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.

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.

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.

Quote:

unless we were to somehow add mirroring control to this mapper or move the PRG bank register down to $6000.

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.

Is there something to be gained by moving to $6000 aside from preventing bus conflicts?

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.

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.

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.

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.

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum