nesdev.org

Posted: **Wed Mar 05, 2014 7:59 pm**

rainwarrior wrote:The FamiTracker driver is about 5.5k of data, as I recall. You can locate it anywhere you like if you build it from source. If you need to bankswitch DPCM, you probably want to keep it out of $C000-DFFF, but other than that there's no good or bad place for it; just depends on your other needs. The ASM or BIN export is just a block of music data, separate from the driver. It can also be located anywhere you like.

Good to know this. So the asm export is just the song data source and together with the FT driver source you can compile the core of an nsf, with freedom to arrange it as needed. To conform to the nsf spec this should be within the PRG ROM space or banked into it?
OK, sorry I've confuse things. The FT driver is the song player within the nsf, right? I was trying to refer to the kernel/wrapper (the nsf player?) that calls the FT driver/song player routine. This is tripping me up a lot, because the nsf has a driver and you need a player to call that driver @ 60Hz or the songs freq. right. I'm really not getting the terminality correct.
But back to a point, as I understand, the nsf player should allow the whole of the PRG 32K for banking of the nsf rip. So does the nsf player code need to be located outside of the PRG 32K space or do most nsf songs stay clear of the top most 1 or 2K?

The only documentation for it is included with the driver source itself, though I did write this guide a long time ago: http://famitracker.com/forum/posts.php?page=1&id=3681

Thanks much, more for my reading list

Yogi

Posted: **Wed Mar 05, 2014 9:04 pm**

If you assemble the FT driver at $E000-$F7FF and the NSF player at $F800-$FFFF, everything should fit. Then you can bankswitch songs into $8000-$BFFF and samples into $C000-$DFFF.

Posted: **Wed Mar 05, 2014 10:45 pm**

tepples wrote:If you assemble the FT driver at $E000-$F7FF and the NSF player at $F800-$FFFF, everything should fit. Then you can bankswitch songs into $8000-$BFFF and samples into $C000-$DFFF.

Thanks tepples. The more I think about the export asm/bin the better it sounds. Thinking of a build tool to target a large Flash with a work flow:
Compose in FT. Export song asm. Multi asm' sorted into a 'album'. Then processed into a standard player template and compiled into a bin to be uploaded. Far more organized and less stressful for users.
This is enticing, will need to research this more.
Yogi

Posted: **Fri Mar 14, 2014 2:19 pm**

EDIT- Yea I figured it out!! The fixed 8K bank at the end of the Bin did the trick.

OK so vegaplay has been in my lab for a couple weeks and I have mutated it a bit. But I'm at a stumbling block.
I have things setup like so:
iNES Header

Code: Select all

    
   .BASE $7ff0
   .DB "NES", $1a
   .DB $04             ; size of PRG ROM in 16kb units
   .DB $00				; size of CHR ROM in 8kb units
   .DB #%01010000		; mapper 85
   .DB #%01010000		; mapper 85
;	.DB #%00000000		; NROM
;	.DB #%00000000		; NROM		
   .DB $02				; PRG Ram
   .DB video			; NTSC or PAL Timming
   .DB $00
   .DB $00
   .DB $00
   .DB $00
   .DB $00
   .DB $00

Then my CHR setup:

Code: Select all

	
       .BASE $8000			; PRG build starts here
RAM_CHR:					; CHR ROM into PRG
	.incbin "geo.chr"			; default Vega Play background

;       ----------------------------------------------------
Load_RAM_CHR:		; 
     src = 0				; ZP Pointer
	lda #<RAM_CHR	; 
	sta src
	lda #>RAM_CHR	; Hi byte of RAM_CHR lable val
	sta src+1
 
	ldy #0       		; starting index into the first page
	sty PPUMASK  		; turn off rendering just in case
	sty PPUADDR  		; load the destination address into the PPU
	sty PPUADDR
	ldx #32      		; number of 256-byte pages to copy
loop:
	lda (src),y  		; copy one byte
	sta PPUDATA
	iny
	bne loop  		; repeat until we finish the page
	inc src+1  		; go to the next page
	dex
	bne loop  		; repeat until we've copied enough pages
	rts

The NSF data loads @ $A64A, the NSF header load address
The Reset and NMI code continues @ $FA00. This works fine with no bank switching in a 32K bin. Just init the VRC7 PRG regs with $00 - $02

If I move the above CHR code to @$10000 in a 64K bin with a .BASE $8000 and try to bank it in over the NSF data only during Reset by writing $04-$06 to the VRC7 PRG registers @ $8000, $8100 and $9000, NO GO. So I don't have my Bin organized correct, right?

What order should I use:
1. The fixed 8K bank ( .BASE $E000 .PAD $10000) as the first block in the bin, follower by bank 0, bank 1 .....to the end of 64K?
2. Or the fixed reset bank at the end of the 64K bin?
3. Of like I've been trying Banks $00-$02, then the fixed 8K, then bank $03 and above?

Here is my banking code:

Code: Select all

   LDX #$03	; bank in $03-$05 Load CHR Ram
   STX $8000	; Reset the 3 PRG banks 
   INX
   STX $8010
   INX
   STX $9000
   JSR Load_RAM_CHR	   ; Load 8K CHR into CHR Ram  
   JSR DrawScreen          ; draw initial nametable
   JSR InitSprites
   LDX #$00     
   STX $8000	; Reset the 3 PRG banks to default
   INX
   STX $8010
   INX
   STX $9000

Thanks for any help,
Yogi

nesdev.org

VRC7 NSF to NES via Vegaplay

Re: VRC7 NST to NES via Vegaplay

Re: VRC7 NST to NES via Vegaplay

Re: VRC7 NST to NES via Vegaplay

Re: VRC7 NSF to NES via Vegaplay