(split from http://nesdev.com/bbs/viewtopic.php?p=73152#73152)
I was designing my tool to handle multiple output formats, both in terms of assembler syntax and targeted music player.
The general design: The tool is split (internally) into three parts:
I had started the middle targeting famitone with back-ends for nesasm and ca65. I was using "diff" against my output with Shiru's "text2data" output to ensure that I was getting byte-for-byte the correct output.
I then wandered off-path and merged the back and middle pieces targeting a famitone inspired music player with ca65 syntax only. Once I get this working, I will then split the back and middle pieces back out.
My main concern with any music player isn't the size of the runtime, but the CPU cycles that it consumes. For my own personal + immediate use, I have a very limited amount of CPU to give to a music player.
This is an example of what I think the tool will look like from a user's point of view:
If input file is not specified, ftm-exporter will read FTM file(s) from stdin. If output file is not specified, asm will be emitted to stdout.
Tool will log warnings and errors to stderr and exit with a non-zero exit code on errors (invalid data in FTM file, etc...). The tool is meant to be Unix / Makefile friendly.
I would like to have a feature where it will intelligently merge multiple FTM files into a single set of emitted assembly. It will identify duplicate instruments and patterns and remove the duplicates. However, I don't need this feature today, so I have not focused on it.
I'll let you guys know when I the tool is stable and I'll put the source somewhere for others to review / modify / use. I host my own subversion server, but I suppose that I could put it on source forge. Ideally, jsr would accept it as a "contribution" to Famitracker, and place the source with Famitracker on source-forge.
I was designing my tool to handle multiple output formats, both in terms of assembler syntax and targeted music player.
The general design: The tool is split (internally) into three parts:
- The "front-end" just parses the FTM file and loads it into a set of data structures.
- The "back-end" is a small set of routines that emits assembler-syntax specific lines of code.
- The converter of "middle" is a set of routines that converts the FTM data into calls to the back-end. The middle is back-end agnostic.
I had started the middle targeting famitone with back-ends for nesasm and ca65. I was using "diff" against my output with Shiru's "text2data" output to ensure that I was getting byte-for-byte the correct output.
I then wandered off-path and merged the back and middle pieces targeting a famitone inspired music player with ca65 syntax only. Once I get this working, I will then split the back and middle pieces back out.
My main concern with any music player isn't the size of the runtime, but the CPU cycles that it consumes. For my own personal + immediate use, I have a very limited amount of CPU to give to a music player.
This is an example of what I think the tool will look like from a user's point of view:
Code:
Usage: ftm-exporter -t target -f format [-o filename.asm] [[-i] filename.ftm]
-t (famitone|gradualore|xyzplayer|...)
-f (ca65|nesasm|asm6...)
-o filename.s
[-i] input.ftm [input2.ftm ...]
-t (famitone|gradualore|xyzplayer|...)
-f (ca65|nesasm|asm6...)
-o filename.s
[-i] input.ftm [input2.ftm ...]
If input file is not specified, ftm-exporter will read FTM file(s) from stdin. If output file is not specified, asm will be emitted to stdout.
Tool will log warnings and errors to stderr and exit with a non-zero exit code on errors (invalid data in FTM file, etc...). The tool is meant to be Unix / Makefile friendly.
I would like to have a feature where it will intelligently merge multiple FTM files into a single set of emitted assembly. It will identify duplicate instruments and patterns and remove the duplicates. However, I don't need this feature today, so I have not focused on it.
I'll let you guys know when I the tool is stable and I'll put the source somewhere for others to review / modify / use. I host my own subversion server, but I suppose that I could put it on source forge. Ideally, jsr would accept it as a "contribution" to Famitracker, and place the source with Famitracker on source-forge.
