oh this is great!
and the artwork rocks as well! :]

18

(0 replies, posted in Nintendo Consoles)

It's here!
https://famitracker.org/fcp4/

19

(4 replies, posted in Nintendo Consoles)

You're exactly right though, that's what he needs to do :]
Look at this link and also this one, you can just

jsr wait_nmi

before each lda / sta pair you do to get up and running, though it's a bit ugly. But hey, it's a start!
Each VBL wait is approx. 1/60 s.

venoSci wrote:

looks like i will need to do some bank switching since bytes $75-$77 are non-zero values

You might need to use this then: https://wiki.nesdev.com/w/index.php/INES_Mapper_031

venoSci wrote:

I appreciate all the help, and I will use this information in order to (hopefully) get something working in the near future.

Thanks!

No problem! :]
Let me know how everytinhg turns out!

venoSci wrote:

how do I determine that the load address is not $8000? Do I simply look for where the bulk of the hex data (song data) is? In my case, the largest chunk of the data IS located at address $8080 (with $8000 being the beginning of the file)

Oh, don't confuse the offsets inside the file (where the song data always starts at byte $80) with the memory layout of the NES. It's possible Deflemask actually does this (have load=$8080), but I don't use it so I'm not sure.
Your data would be located at $8080 if and only if bytes 8 and 9 of the .NSF header are $80.
Also, don't include the first 128 bytes from the .NSF, that's the header. It's metadata and it doesn't belong in the final .NES file.

(Ok, side note here: if the load address is indeed $8080, you could load the entire .nsf file at $8000 and the song data would in fact then be at $8080, because it would be shifted by the size of the header data, so some programs might even do that on purpose, but it's ugly and somewhat confusing! Just read the addresses from the header and then throw the header away. I know, it might take a bit of wrapping your head around all this)

Here's a quick and dirty diagram:

(I've made a test .nsf that is shown there, but the principle is always the same)

Don't worry about $70-$77, just check it's all zeroes (that means no bankswitching). If it's not all zeroes however, you're not gonna be able to use the simple playback method from the nerdtracker example.

Oh, and you can also ask in the nesdev forums, or in the famitracker.org discord (while this discord server is mainly for famitracker users, there are definitely people who know NES programming and might be willing to help, in the #development channel!).

Oh, and to answer your question, each tracker has its own driver code. The FamiTracker NSF driver is even open source, so you can take a peek if you're curious. Games typically include drivers at the source level, NSF was meant more as a format to rip game music to originally.

NSF files can (and do!) have different load/init/play addresses. Take a look here: https://wiki.nesdev.com/w/index.php/NSF.
Download a hex editor if you don't have one, it's invaluable for quickly looking inside .NSFs (I use XVI32 personally). Definitely check you're not playing a bankswitched NSF, that's way more complicated that this example you've posted can handle (to the point of requiring custom hardware).

For non-bankswitched NSFs, this should work. If the load address is not $8000, change the

.org $8000

before

.incbin

Also modify the init and play constants and you should be set!
(I dunno why the code defines the load address and then just hardcodes it, oh well)

Good luck! :]
EDIT: Don't forget to strip the header from the .NSF before including it!

nice!
love the music as well, obviously :]

There is a new version of Reality Adlib Tracker!
From the announcement:

RAD 2 has the following features:

    OPL2 and OPL3 FM support
    Up to 127 separate instruments (up from 31 in RAD 1.1)
    Up to 100 separate patterns (up from 32 in RAD 1.1)
    Up to 128 patterns in the order
    9 channels
    Compact tune file size (even smaller than RAD 1.1)
    Innovative "riff" system
    MIDI support
    Export to WAV feature
    Easy to use

Notably, it has 4op / stereo support, so if you liked the workflow of the original but missed some OPL3 features, this might be for you!

26

(8 replies, posted in General Discussion)

Filled it out, feel free to PM as well :]

27

(11 replies, posted in Releases)

Good job, sounds great!

Hey, nice! Tonari No Toretto is my favorite. Keep it up!

And yeah, awesome cover art as well :]

29

(7 replies, posted in Releases)

Ok, so I've been listening to this all day. I'm so fkn happy this exists! Easily my favorite release of 2017 so far. Now if you'll excuse me, I need to recommend this to everyone in sight :]

30

(7 replies, posted in Releases)

Great stuff!
Thanks for posting, I love the Icarus EP but I've got a feeling this will be a new favorite :]

The cover art is very nice as well!

PM'd

tearauth wrote:

This looks really cool. Was audiosurf an inspiration by any chance? Loved that game

Sure was! I played a lot of it as well :]
The original idea came from my friend, who looked at this video and said it would make for a good game (not really saying what kind of game though):


I immediately thought of the basic idea for the game, made a quick prototype and since it was fun, decided to finish it.
In fact, the original (desktop) version was written in C# and is actually a heavily modified version of the program I wrote for that video. 3D graphics programming is fun!

ryba wrote:

Pěkný! Great, looks cool!

Dík! / Thanks! :]