Deprecated: mysql_connect(): The mysql extension is deprecated and will be removed in the future: use mysqli or PDO instead in /storage/content/49/145849/famitracker.com/public_html/forum/classes/dbHandler.php on line 29
FamiTracker
Any chance that the songs can be exported into 6502 assebler code? I'm trying to learn the basics of it right now and it'd be cool to see how the music is done. If there's an easy way to combine the simple graphics I've been able to produce with music from a .prg file I'd be interested in that to.
Music can be saved as the binary format used by the player code. The assembly code can be found in the download section and NSF driver source, assemble with ca65.
Cool! Though I was hoping for the possibility to export the songs you make into the kind of code that you see in the NSF driver source, the bin files don't really make much sense to me, even in a hex editor, probably because I'm so incredibly new at this.
Anyway... I noticed something interesting. If I change this:
[quote=]; Lookup table
ft_duty_table:
.byte $00, $40, $80, $C0[/quote]
to, say
[quote=]; Lookup table
ft_duty_table:
.byte $20, $40, $80, $C0[/quote]
and replace the nsf sound driver that famitracker uses with a complied version of this edited source, are the square channels going to sound different?? And if this is the lookup table, then why does it start with $00 and not $20? I thought the duty cycles were 12.5%, 25%, 50% and 75%, not 0% (would that even make a sound at all?) 25%, 50%, 75% etc. Maybe these values are referring to something else than the percentage, but the rest of the 4 values there seem to correlate to them, so what's up with the first one?
To be honest, I don't even know what .byte means. Where can I read up on stuff like .db, .byte and such things? All I've found are lists of commands like LDA, RTS and so on, but nothing about the stuff that begin with .db. I've been looking around a bit but still haven't found enough info to explain what most anything does, or why certain commands are repeated (such as in your nsf code - "ror a" is written twice in a row, and so is "lsr a".) I think someone should create a structured (user friendly, like famitracker ) database for all kind of information regarding NES programming, like a wiki or something. I'd happily do it myself if I knew enough about it. Where did you learn all of this incredibly geeky stuff?
Anyway... I noticed something interesting. If I change this:
[quote=]; Lookup table
ft_duty_table:
.byte $00, $40, $80, $C0[/quote]
to, say
[quote=]; Lookup table
ft_duty_table:
.byte $20, $40, $80, $C0[/quote]
and replace the nsf sound driver that famitracker uses with a complied version of this edited source, are the square channels going to sound different??
[/quote]
No, there are values to write on $4000/$4004 registers, and the last two bits are the duty cycle setting for the concerned square channel.
Soooooo , changing $00 to $20 in your example will not affect duty cycle, but will set the lenght counter halt, which in fact will do nothing, because I guess at some point bytes to write to registers are 'OR bitwised' and any note played will set this bit in order not to be limited by the lenght counter.
BIN files just contains the raw music information that is read by the player code, and cannot really be stored as assembly code itself.
For the duty stuff, the driver works on hardware level (naturally), so knowledge of the hardware is necessary to get all details. But as Jarhmander explained, only the two MSB bits are used for setting the duty cycle. Those are defined in hardware as:
Changing to $20 wouldn't affect the duty setting in this case.
.db or .byte (different in different assemblers) just stores data in the memory as bytes. You can think of the BIN file as a big .byte area in the memory where the player reads data from.
And instructions that are written twice are just doing their operation twice. For example lsr a will shift all bits in the accumulator left, which is effective to multiplying by two. Twice will multiply by four.
Don't know if you know about it already, but there is a wiki about NES hardware that might be useful: http://nesdevwiki.org/
That wiki looks to be extremely helpful. I don't know how I could have missed it after looking as much as I have for something like it. It still doesn't explain things as clearly as I'd like it to though. Either that or I just have difficulties learning things this way. I need someone to explain a program in its entirety, every single row, and then work from there. Or sit and rub it all in from somewhere like that wiki until I can make some sense out of it. The wiki seems pretty dead, unfortunately. I wonder why it hasn't been updated in so long.
About the songs that can't be stored as assembly code - can music for the nes be written in assembly code, then?
Yes it can, but you would probably want to organize and store the data in some convenient way, and that's exactly what's done by the tracker. So, you could use the player code and write the music manually as .byte lines, but there's no point doing that.
I wrote a small and simple music driver some time before I started on famitracker that worked that way.
Ok, but let's say I make the rom in nesasm code and the song is in... bin? or prg? ... then what compiler will compile both the song data and my nesasm code into a rom?
Anyway, about that duty cycle - I had to think about it before I got it, but - let's say I write it like this:
.byte $40, $00, $80, $C0
NOW will there be a difference? Will using duty cycle 1 in famitracker now sound like duty cycle 0 normally does and vice versa?
Maybe I should start a new thread for discussing assembler code... anyway, can someone please explain this?[quote=]load_palette:
lda #63
sta 8198
lda #0
sta 8198
rts[/quote]If this code made any sense, the result here would be that at "rts", 8198 = 0, but that's apparently not the case. I thought [quote=]lda #63
sta 8198[/quote] meant "store value 63 at address 8198". If that was the case then [quote=]lda #0
sta 8198[/quote] would mean "store value 0 at address 8198", which would mean that address 8198 = 0. However, it seems that 8198 is now BOTH 63 AND 0. What does "sta" do???
Hey, are there C compilers for the 6502 machine? Would it be convenient and efficient? if so, why messing with assembly that much?
>> Hey, 8198 is $2006 ! WTF, PPU Memory address!!! I would think that an NSF don't touch the PPU, which is not involved at all into the music code!!! It is of no use to set the PPU address to $003F, isn't it? Dafydd, I think you're right about 'sta' (even if I didn't take a look to the 6502 opcodes), but this special address need to successive writes to set a 16-bit value. look at : [url=http://fms.komkon.org/EMUL8/NES.html]http://fms.komkon.org/EMUL8/NES.html
) database for all kind of information regarding NES programming, like a wiki or something. I'd happily do it myself if I knew enough about it. Where did you learn all of this incredibly geeky stuff? 
