Well you have to remember the last bank in the ROM is fixed somewhere, either lower or top 16KB. You need to put all the bankswitching code, NMI, etc. there. Could you post your source possibly? I'll fix it up so it works and show you what's wrong with it.
ETA: More detailed programming MMC1 info:
You need to have a mini boot routine (16 bytes is what you should shoot for. I have a 15 byte routine that returns the bank boot I am going to add below) that resets the mapper by writing >=128 to >=$8000. That will force all MMC1 chips to make the last 16KB be in the $C000 range to execute from, so you can just JMP [$FFFC] to the reset routine in the main bank to make sure it boots correctly. You CAN make the lower $8000 page be executed from, but that's not used or very very useful because when an NMI,IRQ, or RESET occur, the 6502 looks for them at locations $FFFA-$FFFF, so you NEED to have those there all the time. I hope that makes sense. But some MMC1's boot with the 16KB fixed at $C000 first, but ones like the original MMC1 are random and not reliable to assume that. On MMC1B2 I know the boot isn't random like the MMC1 no revision, MMC1B2 boots in the 16KB in the $C000 range. But to make sure it really works on all MMC1's and emus, make sure you have a little reset routine at the end of each 16KB bank.
(Code is for NESASM3, you really should make this a macro to use it.)
.org $FFF0
.db $00
MMC1GlitchBoot:
SEI
LDA #$80+(BANK(MMC1GlitchBoot)/2)
RTIBank14:
STA $8040
JMP [$FFFC]
.dw RTIBank+1 ;NMI
.dw MMC1GlitchBoot ;Reset
.dw RTIBank+1 ;IRQ
Code Comments:
I dunno WHY an IRQ would fire, but just in case I store to $8040 to reset the MMC1, but the $40 is used to also be the instruction for an RTI, so nothing bad will happen if an IRQ happens during reset.
On the LDA, I used that to determine what bank it booted in. It's not needed, just an extra feature.
Any Q's and you can ask. If you use this code....just use it.
Code Comments:
I dunno WHY an IRQ would fire, but just in case I store to $8040 to reset the MMC1, but the $40 is used to also be the instruction for an RTI, so nothing bad will happen if an IRQ happens during reset.
On the LDA, I used that to determine what bank it booted in. It's not needed, just an extra feature.
Any Q's and you can ask. If you use this code....just use it.
Originally posted by: KHAN Games
Here you are.
Here you are.
Awesome. Thanks for the help, I finally got it working.
I think where I was going wrong was that you have to put in exactly double the amount of banks that it says in the inesheader, even if the banks are blank you still have to "declare" them and to number them all in order. I thought that they were just "declaring" them in the examples for clarity. As well, for this mapper I had to specify the chr even though I'm just using one.
It's the one nerdynights tutorial that I didn't find completely clear (though I haven't looked at the sound ones). I'm sure this will sound stupid now, but you know how he says you have to divide the bank numbers by two for the NESASM number? I thought he meant divide the address... so I was using half of $E000 and half of $C000 and trying tons of variations, and then I thought the mirroring might be damaging it etc.
]]>
ETA: More detailed programming MMC1 info:
You need to have a mini boot routine (16 bytes is what you should shoot for. I have a 15 byte routine that returns the bank boot I am going to add below) that resets the mapper by writing >=128 to >=$8000. That will force all MMC1 chips to make the last 16KB be in the $C000 range to execute from, so you can just JMP [$FFFC] to the reset routine in the main bank to make sure it boots correctly. You CAN make the lower $8000 page be executed from, but that's not used or very very useful because when an NMI,IRQ, or RESET occur, the 6502 looks for them at locations $FFFA-$FFFF, so you NEED to have those there all the time. I hope that makes sense. But some MMC1's boot with the 16KB fixed at $C000 first, but ones like the original MMC1 are random and not reliable to assume that. On MMC1B2 I know the boot isn't random like the MMC1 no revision, MMC1B2 boots in the 16KB in the $C000 range. But to make sure it really works on all MMC1's and emus, make sure you have a little reset routine at the end of each 16KB bank.
(Code is for NESASM3, you really should make this a macro to use it.)
.org $FFF0
.db $00
MMC1GlitchBoot:
SEI
LDA #$80+(BANK(MMC1GlitchBoot)/2)
RTIBank:
STA $8040
JMP [$FFFC]
.dw RTIBank+1 ;NMI
.dw MMC1GlitchBoot ;Reset
.dw RTIBank+1 ;IRQ
Code Comments:
I dunno WHY an IRQ would fire, but just in case I store to $8040 to reset the MMC1, but the $40 is used to also be the instruction for an RTI, so nothing bad will happen if an IRQ happens during reset.
On the LDA, I used that to determine what bank it booted in. It's not needed, just an extra feature.
Any Q's and you can ask. If you use this code....just use it.
]]>Code Comments:
I dunno WHY an IRQ would fire, but just in case I store to $8040 to reset the MMC1, but the $40 is used to also be the instruction for an RTI, so nothing bad will happen if an IRQ happens during reset.
On the LDA, I used that to determine what bank it booted in. It's not needed, just an extra feature.
Any Q's and you can ask. If you use this code....just use it.
What more do you need really? The info is all there, what do you need extra to understand it?
I need an example of it. I can't get it to work. I'd be really appreciative of any example of it even if it's from a full game. I'll work it out somehow even if I have to forcibly copy my game and build it around the bank-switching. I've spent hours reading and trying to figure it out and yet still seeing grey screens coming up every time I try to increase the inesprg... ]]>
My problem was not with the criticizm, but with how it was presented. It goes back to what my mommy tells me, "If you are an ass to someone, expect an asshole in return." Constructive criticism is very different than implying that someone doesn't know what they are doing. Making posts that will quite obviously start a flame war = bad.
If someone feels like editing my little write up and PMing or emailing it back to me, I'd be happy to fix it. However, I don't want to sort through this mess to find what is actually helpful.
Bunnyboy, in the future, if you have a problem with something that I am doing, I would hope that it won't take 6 months and an epic flame war for you to let me know what's up. I consider us friends and hope that we can get past this. You have my email addy, my AIM info, and you could even PM me...I won't tell.
I removed my smart ass title to my threads and would be honered if you would help me to fix the problems in this one, the other one, and any future ones that I might post. If it's okay with you, I will add a reference to your thread on MMC1 in this write up somewhere. I feel that we both present the material from different view points that could help a potential user understand the process. If you would like to expand/repair whatever issues you see in my compression thread, that'd be cool. Or if you'd like to write your own, that would be okay as well.
I'd like to remain buds so that I can bug you when I have an issue as I value you as a resource and as a friend.
Peace. ]]>
Except the posts that were erased had all the errors/issues listed above and more corrections needed. Unfortunately not everyone saw them and only the unhelpful angry and painfully formatted posts were kept, I assume to make him look bad. The posts by MRN challenging him in the other thread were also deleted. Where is that undelete post button to show all that?
Ok, I only saw the first few when he was being "dickish". ]]>