Problems with implementing famitone into my code

[andreasswf]

So I've found this cool CYOA-engine at nintendoage and I was trying to implement my music. Turns out when I .inc famitone and put the jsr famitoneupdate and other commands into my cyoa.asm - it crashes the rom or makes the controls unresponsive when I compile it. Have I put the commands in wrong places? This is really giving me a headache. I'll attach the source file for you guys. I've had famitone work with my other small projects, though... When I remove everything with famitone in the code then it works again ...

[tokumaru]

Looks like Famitone and the main program are trying to use the same RAM locations:

FT_BASE_ADR = $0300 ;page in the RAM used for FT2 variables, should be $xx00
FT_TEMP = $00 ;3 bytes in zeropage used by the library as a scratchpad

Famitone needs RAM page 3 and some bytes in ZP, but the main engine is already using those locations for other things:

.rsset $0000 ;;start variables at ram location 0

gamestate .rs 1 ;current state
palettenum .rs 1 ; which palette to use every frame

currentpage .rs 1 ;which page to display

.rsset $0300
pagebank .rs 256 ;data table for bank of each page text

It looks like you don't have a free RAM page that Famitone can use, so you'll either have to make room or use extra RAM at $6000-$7FFF to accommodate everything. When you do find space for Famitone's variables, change the addresses in famitone2.asm accordingly.

[dougeff]

change the addresses in famitone2.asm accordingly

You only need to change the base address definition.

[tokumaru]

You only need to change the base address definition.

The code was intentionally written to make this configuration easy to change, so yes, changing only the base addresses will do it. I'm using the plural because there are 2 base address definitions, one for ZP and another for the other page, and both have to be changed.

[andreasswf]

If i understand correctly, the base adresses are these stuff:

Code: Select all

.org $8000
  .incbin "story.txt"   
  .org $C000
  
  .include "music.asm"
  .include "famitone2.asm"/code]

What would be a good thing to change it to?

[koitsu]

If i understand correctly, the base adresses are these stuff:

Code: Select all

.org $8000
  .incbin "story.txt"   
  .org $C000
  
  .include "music.asm"
  .include "famitone2.asm"/code]

What would be a good thing to change it to?[/quote]
No.  The full explanation was given [url=http://forums.nesdev.com/viewtopic.php?p=180483#p180483]in this post[/url].  You need to change the RAM and zero page "base" locations that the Famitone engine is using (where equates FT_BASE_ADR and FT_TEMP point), as they conflict with the RAM/ZP usage of your program.  However, in your case, you are using all of the RAM/ZP on the system, thus you have no region/area free for Famitone to use.  You need to "free up" some areas of memory for Famitone to use for itself exclusively.

[tokumaru]

If i understand correctly, the base adresses are these stuff:

Nope, this is where the code is placed in the ROM, and I don't think you have any problems with that. The problem is that the main program and Famitone are trying to use the same RAM positions for different purposes, meaning they keep overwriting/corrupting each other's variables.

The code you have to change is the part of Famitone I showed in my previous post. You do seem to have a lot of ZP free, so you could easily change FT_TEMP to $0D, to use the last 3 bytes of ZP ($0D, $0E and $0F), for example. But Famitone also needs an entire page of RAM, and is currently trying to use $0300, which is already in use by the main program, and it doesn't seem like there are any free pages you can use (all pages up to $700 are taken).

You either have to modify the main program to free a RAM page for Famitone to use, or, if you can't modify the program, enable extra RAM at $6000-$7FFF and set Famitone's FT_BASE_ADR to any page in that range. The main disadvantage of using extra RAM is that it will make cartridges more expensive to build, in case you're planning to do that. If not, this isn't a big deal.

If you're not using an NES 2.0 header, I believe $6000-$7FFF contains RAM by default in some emulators (this might depend on the mapper, though), so you could try simply changing FT_BASE_ADR to $6000.