Mapping Help - MMC 1

[nineTENdo]

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

[Zzap]

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: Select all

  .inesprg 2   ; 2x 16KB PRG code

Then you can define the banks like so:

Code: Select all

  .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.

[nineTENdo]

ok its worked but on wierd conditions. this how my lay out was:

Code: Select all

 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?

[tepples]

In an NROM-256, inesprg is 2 (four banks), vectors must be in bank 3, and CHR must be in bank 4.

[MottZilla]

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.

[tepples]

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.

[MottZilla]

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.

[kyuusaku]

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.

[nineTENdo]

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?

[tepples]

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.

[MottZilla]

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

[nineTENdo]

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?

[tepples]

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.

[bunnyboy]

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.

[doynax]

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: Select all

		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.