It is currently Sun Jul 15, 2018 11:23 pm

All times are UTC - 7 hours

Post new topic Reply to topic  [ 17 posts ]  Go to page Previous  1, 2
Author Message
PostPosted: Fri Mar 09, 2018 1:12 am 
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7443
Location: Chexbres, VD, Switzerland
If I remember well mapper #11 is basically a nybble swapped mapper #66 with lockout defeat, so it's not much more interesting to use than #66.

As for #66 I believe there's two fundamental reasons it's less often used:

1) Simply put, it's much deeper in iNES mapper numbering than other common mappers. For that reason, it is more likely to be ignored and/or not considered as an option. Even if it's a Nintendo official mapper.
2) 8 KB CHR-ROM banking is often impractical, as it means that whole sprite sheets have to be swapped with BG sheets. For smaller and simple games which fits in 32 KB PRG (CNROM) it's not so much an issue as it's possible to have simple gameplay and either 3 or 4 level graphics layouts. But for larger games which uses more PRG, it becomes a handicap to have only 4 pages of CHR-ROM which have to be wholly switched, as opposed to finer grained CHR-ROM switching.

PostPosted: Sun Mar 11, 2018 5:46 am 

Joined: Mon May 27, 2013 9:40 am
Posts: 466
dougeff wrote:
but seems like most don't agree or fully understand what to do in order to take advantage of 32KB banking

1.copy some bank switch code into the RAM
2.jump there to switch banks, then jsr to a entrance code part of the bank, which reads the game state and uses a jump table to get to the appropriate subroutine
3.have a reset code in every PRG bank which can return you to the main bank, if the user presses reset.

The advantage of 32k PRG banks would be to have a contiguous code block or data block that doesn't need to be split awkwardly.
Music code and data might benefit from having its own 32k block.

The disadvantage would be, DMC samples might have to be copied in more than 1 bank, wasting space.
And, CHR banks are less efficient, if you have the same graphics partially copied in multiple 8k CHR banks.

I suppose, you lose mirroring changes, without the MMC. And no scanline counter.

EDIT - every bank needs an NMI handler too, which does not bode well for "all in the NMI" style programs

You don't need to be that fiddly - I mean having to copy the routine to RAM. I usually reserve some bytes just beside the vectors in each ROM, and copy the same exact bankswitching code. When you change banks, the new banks will have the exact same contents, so no problems.

I usually work with a set of NROMs I paste together using a custom tool which writes the correct iNES header as well.

INL's extended mapper 11 gives you up to 16 32K PRG-ROM pages and 16 8K CHR-ROM pages with bus conflicts, but you don't usually need every combination of PRG and CHR accessible from every bank, so I use an indexed table of the actual values. Such table can lie anywhere on ROM. So my setup is something like this:

cc65 cfg:

    RJM: start = $ffc0, size = $3a, file = %O, fill = yes;

    ROMCHGR:  load = RJM,          type = rw;

.segment "RODATA"
   ; This can be big so place here
   .include "bus_conflict_tbl.s"

.segment "ROMCHGR"
   lda #0
   sta PPU_MASK
   sta PPU_CTRL

   ldx $0300
   lda bus_conflict_tbl, x
   sta bus_conflict_tbl, x

   jmp start

   ldx $0300
   lda bus_conflict_tbl, x
   sta bus_conflict_tbl, x

"bus_conflict_tbl.s" has the table with the PRG/CHR combinations I need in every PRG bank. _change_rom does the bank switch, then jumps to "start", which contains the initialization code. _change_reg just bankswitch, which is mostly used when you are just changing the paged CHR-ROM.

This is an example of "bus_conflict_tbl.s"
   ; This ROM pages in PRG0:CHR0, PRGD:CHRD or PRGB:CHRD

      .byte $00, $DD, $DB

My initialization clears all RAM but a small section I use so the different ROMs can communicate. I perform a simple CRC-like check on these values to invalidate them. If an invalid combination is found, all banks page in PRG0:CHR0, which works great as mapper doesn't guarantee an initial state.


Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 17 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours

Who is online

Users browsing this forum: No registered users and 4 guests

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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group