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
Should the nsf driver source include a guide to compiling the drivers? Modifying the NSF driver to build into Famitracker takes a bit of figuring out. This is what I've done:
1. The driver is loaded at $8000, attached is an appropriate .cfg file for ld65.
2. Assemble driver.s with -D USE_XXX. (One for 2A03 solo, and each expansion.)
3. Link with ld65.
4. Convert binary output to header file (drv_xxx.h) for use in famitracker/Source/drivers
5. With the latest version there is a config.h in /drivers with pointers to data structures in the driver. These pointers can be found by using -g when assembling, and -Ln labels.txt when linking to generate a list of labels and their addresses.
Yeah that guide should work, except that the driver can be relocated but it's easily modifiable to a fixed address. I'm using a bunch of scripts to build the header files, I should probably document the process somewhere.
Actually only two places are used: one to minimize the size when DPCM samples is used and bankswitching disabled and one when bankswitching is enabled. The reason to keep two variants available is to make the exported NSF easy to embed in NES programs, and initially also because I had a 32kB dev-cart (back before the Powerpak was available) which only supported non-bankswitched files, so I wanted to avoid bankswitching unless it was actually needed.
Previous versions had two different copies of the same driver located at different addresses, but I rewrote large parts of the exporting code in 0.4.0 and then also added dynamic relocation. The main reason for the rewrite was to add symbolic assembler output for easier debugging.
It's a little more complicated, but it saves some trouble with manually setting up the addresses and won't have to store drivers multiple times. I'm using the cc65 object file converter and then parses the text output. I tried to figure out the object file format first, but this was easier. :)
The config.h addresses is generated from the listing file.
Yeah it's co65 and it's using a format called o65 which has to be built with the linker, so the process is ca65 -> ld65 -> co65. The output format from the linker is set to o65 in the linker config file.