a_dinosaur/VGM-Tools
1
0
Fork 0
mirror of https://github.com/ScrelliCopter/VGM-Tools synced 2025-02-21 04:09:25 +11:00
Code Issues Releases Wiki Activity

Reorganised slightly, and added my spc sample ripper + spc2it.

Browse Source
This commit is contained in:
a dinosaur
2018-09-03 02:45:47 +10:00
parent 48dcc09399
commit 45ec9cf2cf
28 changed files with 6195 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

160
spctools/spc2it/doc/LICENSE_SNEESE Normal file
View File

@@ -0,0 +1,160 @@
This license is a free software license, compatible with the GNU General
Public License (GPL). It is the minimal set of changes needed to correct
the vagueness of the Original Artistic License.
Text'ified by Randy McDowell (stainless* *at* *users.sourceforge.net).
SNEeSe is copyright (c) 1998-2006, Charles Bilyue'.
Portions copyright (c) 1998-2003, Brad Martin.
Portions copyright (c) 2003-2004, Daniel Horchner.
Portions copyright (c) 2004-2005, Nach. ( http://nsrt.edgeemu.com/ )
Unzip Technology, copyright (c) 1998 Gilles Vollant.
zlib Technology ( www.gzip.org/zlib/ ), Copyright (c) 1995-2003,
Jean-loup Gailly ( jloup* *at* *gzip.org ) and Mark Adler
( madler* *at* *alumni.caltech.edu ).
JMA Technology, copyright (c) 2004-2005 NSRT Team. ( http://nsrt.edgeemu.com/ )
LZMA Technology, copyright (c) 2001-4 Igor Pavlov. ( http://www.7-zip.org )
Portions copyright (c) 2002 Andrea Mazzoleni. ( http://advancemame.sf.net )
- The Clarified Artistic License -
i. Preamble
The intent of this document is to state the conditions under which a
Package may be copied, such that the Copyright Holder maintains some
semblance of artistic control over the development of the package, while
giving the users of the package the right to use and distribute the
Package in a more-or-less customary fashion, plus the right to make
reasonable modifications.
ii. Definitions:
"Package" refers to the collection of files distributed by the Copyright
Holder, and derivatives of that collection of files created through
textual modification.
"Standard Version" refers to such a Package if it has not been modified,
or has been modified in accordance with the wishes of the Copyright
Holder as specified below.
"Copyright Holder" is whoever is named in the copyright or copyrights
for the package.
"You" is you, if you're thinking about copying or distributing this
Package.
"Distribution fee" is a fee you charge for providing a copy of this
Package to another party.
"Freely Available" means that no fee is charged for the right to use the
item, though there may be fees involved in handling the item. It also
means that recipients of the item may redistribute it under the same
conditions they received it.
iii. Context
1. You may make and give away verbatim copies of the source form of the
Standard Version of this Package without restriction, provided that
you duplicate all of the original copyright notices and associated
disclaimers.
2. You may apply bug fixes, portability fixes and other modifications
derived from the Public Domain, or those made Freely Available, or
from the Copyright Holder. A Package modified in such a way shall
still be considered the Standard Version.
3. You may otherwise modify your copy of this Package in any way,
provided that you insert a prominent notice in each changed file
stating how and when you changed that file, and provided that you do
at least ONE of the following:
a) place your modifications in the Public Domain or otherwise make
them Freely Available, such as by posting said modifications to
Usenet or an equivalent medium, or placing the modifications on a
major network archive site allowing unrestricted access to them,
or by allowing the Copyright Holder to include your modifications
in the Standard Version of the Package.
b) use the modified Package only within your corporation or
organization.
c) rename any non-standard executables so the names do not conflict
with standard executables, which must also be provided, and
provide a separate manual page for each non-standard executable
that clearly documents how it differs from the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
e) permit and encourge anyone who receives a copy of the modified
Package permission to make your modifications Freely Available in
some specific way.
4. You may distribute the programs of this Package in object code or
executable form, provided that you do at least ONE of the following:
a) distribute a Standard Version of the executables and library
files, together with instructions (in the manual page or
equivalent) on where to get the Standard Version.
b) accompany the distribution with the machine-readable source of the
Package with your modifications.
c) give non-standard executables non-standard names, and clearly
document the differences in manual pages (or equivalent), together
with instructions on where to get the Standard Version.
d) make other distribution arrangements with the Copyright Holder.
e) offer the machine-readable source of the Package, with your
modifications, by mail order.
5. You may charge a distribution fee for any distribution of this
Package. If you offer support for this Package, you may charge any
fee you choose for that support. You may not charge a license fee
for the right to use this Package itself. You may distribute this
Package in aggregate with other (possibly commercial and possibly
nonfree) programs as part of a larger (possibly commercial and
possibly nonfree) software distribution, and charge license fees for
other parts of that software distribution, provided that you do not
advertise this Package as a product of your own. If the Package
includes an interpreter, You may embed this Package's interpreter
within an executable of yours (by linking); this shall be construed
as a mere form of aggregation, provided that the complete Standard
Version of the interpreter is so embedded.
6. The scripts and library files supplied as input to or produced as
output from the programs of this Package do not automatically fall
under the copyright of this Package, but belong to whoever generated
them, and may be sold commercially, and may be aggregated with this
Package. If such scripts or library files are aggregated with this
Package via the so-called "undump" or "unexec" methods of producing a
binary executable image, then distribution of such an image shall
neither be construed as a distribution of this Package nor shall it
fall under the restrictions of Paragraphs 3 and 4, provided that you
do not represent such an executable image as a Standard Version of
this Package.
7. C subroutines (or comparably compiled subroutines in other languages)
supplied by you and linked into this Package in order to emulate
subroutines and variables of the language defined by this Package
shall not be considered part of this Package, but are the equivalent
of input as in Paragraph 6, provided these subroutines do not change
the language in any way that would cause it to fail the regression
tests for the language.
8. Aggregation of the Standard Version of the Package with a commercial
distribution is always permitted provided that the use of this
Package is embedded; that is, when no overt attempt is made to make
this Package's interfaces visible to the end user of the commercial
distribution. Such use shall not be construed as a distribution of
this Package.
9. The name of the Copyright Holder may not be used to endorse or
promote products derived from this software without specific prior
written permission.
10. THIS PACKAGE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.

296
spctools/spc2it/doc/OPENSPC.TXT Executable file
View File

@@ -0,0 +1,296 @@
This is a modified version of OpenSPC 0.301, improved by Dwedit,
with support of fractional update rates to generate better IT files.
See http://www.romhacking.net/forum/index.php?topic=10164.0
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
OpenSPC ver.301
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
Intro
-----
OpenSPC is an SPC Player created using a modified version of SNEeSe's ASM SPC
core. The rest was written in C using DJGPP. You can find new versions and
a FAQ for OpenSPC at:
http://home.gvi.net/~martin
OpenSPC was created by Butcha, and has been contributed to by Cyber Warrior X,
Crono, Kadar, and Cait Sith 2.
++++++++++++++++
Table of Contents
--------------------------------------------
1.) What's New
2.) Disclaimer and License
3.) System Requirements
4.) Current Progress
5.) Future Progress
6.) Configuration File
7.) IT Dumping
8.) Credits/Special Thanks
+++++++++++++
1.) What's New
--------------------------------------------
v0.301 - Relatively small update
* Added ID support for SPC files (thanks to Cait Sith 2). Displays info for
SPC files that contain it, in both the lite version and the full version,
non-gui mode.
* Changed "SPC->IT conversion" name in IT files to the ID song name if
specified in SPC file.
* Updated to SNEeSe version .36 SPC code, including all optimizations and
bugfixes that were present in it.
v0.300 - Another big (and overdue) update
* Prevented notes that are out of IT's range from writing the invalid data -
prevents IT corruption, but probably still won't sound quite right.
* Checked for invalid loop points supplied by an SPC file (wouldn't think
you'd *need* to check... %#!@$).
* Updated display screen with new pitch when sliding.
* Fixed rare bug which allowed volumes with opposite signs in both channels
to cancel each other out when in mono mode.
* Corrected bug where if a voice was keyed off at the same time the sample
ended, the voice would not get turned off. Prevents the big long strings of
note cut commands sometimes seen in the IT files.
* Decided to scrap my sound drivers in favor of Allegro's. This means both
the Ensoniq SoundScape and ESS AudioDrive should now be supported in addition
to all SoundBlaster types. Note only the sound driver, not the mixer, has
been replaced.
* As a side effect of this, the onscreen display updates slower now, because
Allegro requires much more sound data to be mixed and delivered at once.
This is much more noticable with frequencies less than 22050 Hz.
* Config file rewritten to reflect changes in sound driver. Should still be
compatible if you have any old frontends, but I'm not sure.
* Corrected a bug in ADSR/GAIN which could cause the envelope height to wrap
around infinitely. (Jurassic Park)
* Implemented main volume registers
* Changed to the newest version of SNEeSe SPC core. TCALL (and therefore
Terranigma) now works! Other optimizations and fixes are also present.
* Changed to SNEeSe's SPC timer code. Timers are now cycle-exact rather than
calculated once every update.
* Reimplemented ADSR/GAIN in the style of the timer code, which means it is
now cycle-exact. Any song that changed envelope states while monitoring ENVX
should now work much better.
* Doubled output volume both in the mixer and in IT dumping. This can
potentially cause clipping distortion while mixing and maxed-out volumes in
IT files if the volume ever gets too high, but it seems SNES games rarely
use high volume which is why it sounded so quiet in the first place.
* Fixed up the display for text mode. Colors and layout should be identical
to the graphics mode, especially if used with an 80x50 screen. Use setgui=2
in the config file to activate.
* Implemented a command line switch equivalent to the setgui parameter in the
config file. (-g x)
* Fixed up the colors on the display and allowed the colors to be changed in
the config file.
* Did a little cleaning and optimization of the source code.
v0.200 - Lots new in this version
* Allowed IT dumping with other than 200 rows/pattern (change in CFG file)
* Fixed bug with volume and IT dumping (played too loud and would
sometimes result in undesired volume column effects being applied)
* Fixed segmentation fault bug when a negative volume applied to a channel
* Fixed a bug with GAIN linear decrease mode
* Fixed file loader bug when filename preceded with "..\" <Doh, stupid me>
* Fixed file loader bug when loading files with extension .SP1, .SP2, etc.
* Increased number of SPC cycles to execute, while simultaneously
implementing system to pause emulation if SPC idle. Should prevent games
like Starfox from slowing down and speeding up, and *might* even save some
CPU power in other games
* Got rid of the "SPC Sample" for samples without lengths. (Thanks to Crono)
* Added .IT pattern compression. (Crono)
* Reduced memory requirements when *NOT* logging a .IT file (Crono)
* Now uses "specific" mixing method for each style of output. (Crono)
* Old Soundblaster drivers tweaked, should sound better and can now go up to
45454 Hz. May introduce some incompatibility, let me know. (Crono)
* Soundblaster Pro drivers tweaked, hopefully sound better. (Crono)
* Moved actual emulation stuff from main.c to emu.c. main.c now only
contains main() and other graphics-related stuff.
* Added support for Ensoniq Soundscape, SoundFX and MediaFX cards (thanks to
Kadar)
* Added support for non-standard IRQs. Let me know if you still have
problems getting it to play on your SB-compatible sound card.
* Found and eliminated something WinAmp wasn't liking about the way unlooped
samples were saved.
* Created 'lite' version! Now capture SPC's to either IT or WAV files
direct to disk at maximum speed rather than having to listen to them.
Uses command line options to specify parameters. (Replaced 'main.c' with
'lite.c' and removed sound drivers in project file)
* Added many of the same command line options to the full version. If no
options are specified it will default to what's in the OPENSPC.CFG file.
* Added a preset time limit and current time indicator to both versions.
* Replaced the SNEeSe SPC core with a newer version; had hoped this would fix
some SPC bugs, but no luck there. Oh well, hopefully its faster or
something.
* Broke down and did some SPC debugging myself; managed to get Prince of
Persia, WWF, Doom, FF2 (Fabul Castle), SOM2 (Boss Theme), and Simpsons:
Bart's Nightmare working a lot better.
Details: - all SBC to memory were subtracting in the wrong order
- CMP YA, dp didn't complement the carry flag
- membit addressing mode operand bits were mapped incorrectly
* Corrected some bugs in GAIN Increase and Decrease modes and re-enabled
ENVX reporting; made WWF, Doom, and Simpsons sound even better.
* Added a reverse stereo option for those of you experiencing swapped sound
channels with an SBPro compatible.
v0.100 - Initial release
+++++++++++++++++++++++++
2.) Disclaimer and License
--------------------------------------------
This program is still considered to be in beta status. Neither Butcha nor any
of the other contributors are responsible for any undesirable effects of using
this program. Also, none of the authors are responsible for the possesion or
use of any copyrighted material taken from copyrighted ROMs using this
program.
Please do not redistribute this program without its included documentation.
Also, do not package this program with SPC or IT files from copyrighted games.
++++++++++++++++++++++
3.) System Requirements
--------------------------------------------
The light version should have very few requirements. Probably a 386 with an
FPU could run it, but I can't say for sure. Memory shouldn't be a problem as
long as you have some available swap space. The following are some tentative
guidelines for the full version:
Minimum Recommended System:
- 486/100 processor
- 8MB RAM
- Sound Blaster or compatible card
Strongly Recommended System :
- Pentium processor (P133 or higher)
- The more RAM the merrier (especially with Windows 9x)
- VGA card (for graphical display)
- Sound Blaster 16 or 100% compatible
+++++++++++++++++++
4.) Current Progress
--------------------------------------------
The following are implemented in the sound engine:
- 16bit digital stereo sound
- SPC700 Sound CPU (likely still bugs to be found)
- FULL ADSR and GAIN volume effects (now cycle-exact!)
- Song capture in the IT format
- Sound recording to WAV format (lite version only)
The following are missing in the sound engine:
- ECHO
- FIR filter
- Noise
- Modulation
The following are some known bugs:
- If the pitch changes too fast while a note is on, an IT file will not be
able to reproduce it fast enough, resulting in a subtle "rounding" effect.
(i.e. FF3 Atma Weapon)
- A few games' music doesn't like being played with a fixed update-per-second
method, resulting in unpredictable effects
- Any game that changes the sample location or data while playing will sound
strange (Doom, Cannon Fodder). No easy work around this, because ITs always
expect the same sample to stay the same.
- Dragon Quest seems to have some severe bugs, no idea why
++++++++++++++++++
5.) Future Progress
--------------------------------------------
Future progress is completely indefinite at this point, due to my currently
attending college at UMR. I haven't had a lot of free time here, and that
which I do have I will most likely be devoted to other things. As far as
major features missing from the program go, there isn't a whole lot more
I can add, because it wouldn't transfer into an IT file anyway (echo, filter).
Noise and modulation might be possibilities, I'd have to look more into it. I
would like to have a much better display, but I keep saying that and never get
around to working on it. Also, there are the above bugs to fix. I would
however like to rewrite the IT code to save more data temporarily into a
proprietary format, and then convert this data to an IT file. This would make
it easier for other people to add support for other filetypes. It could also
make the IT code itself more efficient in compressing the resulting file. I
have no idea when or if I'll get to this, however. We'll see.
+++++++++++++++++++++
6.) Configuration File (not in lite version)
--------------------------------------------
Any documentation you need for the configuration file should be found in
comments inside the OPENSPC.CFG file itself. If you've let some frontend
overwrite it and you can't find any comments, you'll have to restore from the
original ZIP. I recommend backing up the config before using any frontends,
if the frontend doesn't do so itself. Do NOT delete this file, OpenSPC will
NOT regenerate it.
+++++++++++++
7.) IT Dumping
--------------------------------------------
IT dumping is done via 16 channels(8 channels each with independent left and
right volume control). When you switch on IT dumping, everything you hear in
the player is saved into the IT file. This means the IT file starts on the
first note of the SPC and ends when you hit a key to end recording. Upon
pressing a key, a note cut command is issued across all 16 channels, along
with a command to loop back to the beginning of the song. This makes it easy
to record simple looping songs-simply hit a key just before the first note of
the song plays again, and it should sound pretty decent. However, many songs
have an "intro" that they play first, and then go into another section and
loop. To make these loop correctly, you will have to manually edit the IT
yourself. I will describe how to do it using Impulse Tracker; it is up to you
to figure it out if you use a different one, but it shouldn't be much
different.
- First of all, switch on IT dumping and play the song. Stop recording a
second or two after you hear it loop.
- Open up the resulting IT file in Impulse Tracker.
- Find the first note of the section that loops. If it is at the beginning of
a pattern, you are incredibly lucky. If not, go to the next pattern and see
where it begins with relation to the music(for example, say the pattern
begins 5 rows before channel 2 plays a C#5). Also, remember which pattern
number it is.
- Go find the end of the song. Locate the first note of the looped section,
then look forward until you find the spot you remembered(5 rows before
channel 2 plays C#5, in our example). Hit ALT-DEL to delete everything in
this pattern after that spot. When the pattern is clear after that spot,
put the cursor on the effects column of any channel and enter in effect 'B'
followed by the number of the pattern you found in the last step(in hex).
- Once you've completed this, you'll probably want to delete any extra
patterns after this one, along with their respective orders.
- Play it. Sound right? Save it. If not you either found the wrong spot or
entered in the wrong pattern number.
It may sound a little complicated or awkward, but its really not that bad when
you've done it a few times. I did it 16 times to create the examples on my
webpage. If you'd like you can open them up for an example.
+++++++++++++++++++++++++
8.) Credits/Special Thanks
--------------------------------------------
Thanks go to:
- Savoury SnaX and Charles Bilyu‚ for the SPC code used in this project.
- Shawn Hargreaves (and others) for the Allegro library
- Citizen X for letting CWX see the WinSPC source for ideas
- Gary Henderson for helping CWX with SPC Dumping and with Terranigma
- The rest of the Snes9x team for their hard work and the release of the
Snes9x source code, although this program contains no Snes9x-derived code.
- zsKnight and _Demo_ for an awesome emulator and for inventing SPC files
(even though I still think I came up with the idea for playing a sound save-
state first :)
- TheGun and SailorStarFighter for some early betatesting (hi guys :)
--Butcha

180
spctools/spc2it/doc/Readme.linux Normal file
View File

@@ -0,0 +1,180 @@
OpenSPC v.300Linux (based on Lite/Direct To Disk version)
Linux port and general code tweaking by Chris Timmerberg (ctimmerb@usa.net)
Hi! Here's the long-awaited port of OpenSPC to linux. I say linux, primarily
because that's all I'm able to test it with (at least presently). If your
platform is relatively portable and has a /dev/dsp it may very well work
there as well. It may even work with code that pretends to be /dev/dsp, such
as I've seen for Os/2. This is completely speculation, I've never tried it.
Even in the lack of /dev/dsp, you should still be able to compile it almost
everywhere there's a gcc or other standard compiler. This will give you full
wav/it dumping facilities, as well as the ability to pipe stdout into
another player app which handles wav-like data. I've found splay to work
fine. Again, I havent tested others. Feel free to do so yourself.
The tty files were copied from another project and as such contain alot of
extra stuff #ifdef'ed which linux doesnt use. I can't say whether or not
these other code blocks work on their respective platforms, sorry.
The binary I send along was built on my 486 running Stampede. It uses no
extra libraries beyond Glibc 2.1. Everyone should have this by now. If you
dont, feel free to compile your own copy (of the OpenSPC, or of glibc).
PGCC 1.1.3 was used. The makefile includes -O6 -mpentium optimization levels
by default. This seems to generate the best quality code for most people's
systems. And no, mpentium DOESNT seem to harm a 486 any. My 486 is doing
just lovely playing back the spc's I've tried. I always use at least these
options when compiling everything (occasionally a couple extras in
addition).
The overall behavior of this port is somewhat different from the original.
Assuming one has enough cpu power (it shouldnt be hard to, my 486 did it)
you can dump to several destinations at the same time. This includes wav
file, IT file, stdout, and soundcard. The program code sets all output
variables to 0. Options you specify for -w -i -p and -l then turn on any of
the 4. If none was specified it turns on wav. Each enabled option is then
checked for success and if necessary turned off. If no output options remain
it finally gives up, and exits.
Data is written directly to /dev/dsp. The original code made no attempt to
buffer writes, and I didn't make any modifications in that area. As far as I
can tell, /dev/dsp and/or the soundcard itself have at least a small buffer.
This is probably not sufficient to prevent breakups if you're doing
something cpu-intense. A buffer may be added eventually...
Several command line options were added:
-l enables the audio card output code. As many sound cards do not possess an
exact frequency match, the audio output is by default tweaked to match what
your soundcard reports it was set to. This does not SEEM TO affect it
output, but does affect wav. If your card's status report was in error or
your goal was to dump an exact frequency wav you may disable the adjustment
with the -a option.
-p enables piping support. This data is identical to that which is fed to a
wav file or /dev/dsp. You may send this directly to an audio player of your
choice.
The -P option to accept input from stdin is wishful thinking for a next
version. It'd be nice to be able to zcat, bzcat, or unzip -c compressed spc
file(s) into this player, and beats trying to write support code for
handling different compression methods.
Aside from everything mentioned above, the base code remains for the most
part, unchanged. I include the two text files from the original dos version,
renamed to openspc.dos.txt and source.dos.txt.
The next version may also include as well as the mentioned earlier buffering
system and input pipes, the ability to batch play multiple files, general
code cleanup and optimization, and maybe some other sound file formats...
Candidates for other formats include gym, cym, nsf, and anything else that
isnt supported by other linux players. Within reason, and as long as my 486
handles it reliably. :)
If you want a netscape plugin, write it yourself. I dont do netscape
plugins. (Netscape is piggish enough on a 486 without having MORE overhead,
thank you very much!!) Meanwhile this existing program SHOULD work as a
'helper app' type thingy. No I didnt test that either.
Misc note: This program uses <__math.h> for the pow2 and __log2 functions.
These functions generate inline assembly code, which is both shorter and
faster than calling external library functions from linking with the -lm
option.
Using code from the NORMAL <math.h> header I've determined to
require an alternate sequence of:
#define __USE_EXTERN_INLINES 1
#define __USE_ISOC9X 1
#include <math.h>
This also changes the function names required, to log2f and __pow2
Oddly enough, the code generated by this contains many more instructions of
overhead.
<__math.h> generates a warning about __log1p which I dont even use. This
warning seems to be due to a bad header file, not my code. The warning is
harmless and may be ignored. The other warnings are going to be cleaned up
eventually.
Release notes for version .201Linux:
* Overlooked changing a few instances of 'dump' into 'itout'. This caused IT
dumping to generate incomplete files.
* WAV dumping no longer generates any temp files
* Upgraded from PGCC 1.1.1 to 1.1.3, and threw in -ffast-math in
compilation options.
* Accidentally packed 'source.dos.txt' into the archive twice the first
time around. Only need ONE copy of this :)
Release notes for version .300Linux:
* Downloaded dos version .300 and re-implemented all my changes including
stripping _ symbols in .S files, #including <__math.h> in sound.c, and
tons of stuff in lite.c
* lite.c now features a shutdown function for orderly shutting down.
* lite.c has two extra \r characters by popular demand :)
* Patched spcmain.S to not use self-modifying code in SPC_READ_RAM_ROM
Release notes for version .301Linux:
* Features migrated from the .301 dos version finally - id666 tags and new
spc core. The id tags allow the player to know how long to play a
particular file for.
* The code from the dos version's lite.c was WRONG WRONG WRONG and
generated really silly play times. So I fixed that and changed it to
read the whole id tag header into a 'struct' all in one read.
* The code for -t was also slightly incorrect in the dos version and my
previous release. We now handle all three cases: seconds only with and
without a leading colon, as well as the previous minutes:seconds case.
Also properly handles stuff like 90 or :90 or 0:90 (or even 1:90)...
* spcmain.S from the dos version included more silly self-modifying code in
.301. When will they learn??? .... fixed
* Dos version collided with my usage of the -l parameter. I kept mine, -l
is still linuxout audio method, and a capitalized -T is used to disable
the playback length mentioned in the idtag resulting in unlimited length
playbacks.
* Changed some of that math.h stuff. Gcc 2.95.2 (and pgcc) seem ok with it
the way I have it now, and I didnt feel like playing with it anymore...
* Tried to implement a 'large buffer' option to avoid audio breakups. Ended
up with WORSE breakups. Someone wanna look that over and see what I
missed?
* Meanwhile, I upgraded to a nice Trident 4Dwave card and now am running
with the Alsa drivers (.58a as of this writing). Program works lovely by
default. (At least as long as you've got the oss emulation modules, but
you do, dont you?? :) This card at least gives me the exact sample rates
I ask for, but I'm sure alot of people out there still have cards which
dont so I didnt touch the rate-tweak logic.
If you want a large buffer and to use native alsa playback, try
something like: ./ospc -p CT-1-22-TheHiddenTruth.spc | bag | aplay -m
'bag' is a nice buffering utility that I think came with Timidity's
tools, and aplay is part of the Alsa stuff. Dont bother trying this
approach with certain other play utilities, in particular avoid the one
from sox. You can identify this crappy 'play' program by typing 'play'
and seeing if it says its a frontend to sox. Sox's play just soaks up
tons of cpu and does NOT help (the point of HAVING a buffer is to try
to avoid cpu usage spikes from breaking up the audio, after all!!)
* The dos version did not yet support the id tag's 'fadeout length' value,
and I have not tried to do anything about this yet either. Feel free to
do so for me. :)
I was thinking maybe to use the oss or alsa mixer controls. Note that at
least for my trident, the oss-emulation 'main volume' seems to be using
one of trident's 32-position ones (despite showing in the oss mixers as a
1...100 range), making for rather unsmooth fading if one were to use that.
In fact, all of the trident's volume knobs can get a bit confusing to sort
out. There are at least several availible from alsa mixers with a full 255
position range at least. (I use xamixer. gamix is also nice. Neither is
totally perfect though.)...
* Some extra keypresses - q and escape quit as well as the previous
spacebar. New key functions include p or s to pause. Other activity
such as fast forward and rewind seem awfully difficult to implement. Feel
free to try doing so yourself as always :) Note that quiting or pausing
seem to take place after the buffer is emptied (or at least not QUITE
instantly). Good enough though.
* If you feel compelled to,
make ospcshared
cp -a libspc.so /usr/lib/libspc.so.0
(or any other suitable directory, or just edit your LD_LIBRARY_PATH)
Works here, your milage may vary.
* Changed Makefile to use CFLAGS, and included a nice flag setting for
optimization which I got from who knows where (probably an old posting to
the xmame mailing list).

173
spctools/spc2it/doc/SOURCE.TXT Executable file
View File

@@ -0,0 +1,173 @@
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
OpenSPC ver.300
Source Code
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
/ntro
-----
OpenSPC is an SPC Player created using a very modified SNEeSe SPC CPU core.
It was made in C (although the SPC core is in Assembly) using DJGPP. You can
find new versions and a FAQ for OpenSPC at:
http://home.gvi.net/~martin
OpenSPC was created by Butcha, and has been contributed to by Cyber Warrior X,
Crono, and Kadar.
++++++++++++++++
Table of Contents
--------------------------------------------
1.) Disclaimer
2.) License Rights
3.) Programming Conventions
4.) Brief Outline
+++++++++++++
1.) Disclaimer
--------------------------------------------
This program is still considered to be in beta status. Neither Butcha nor any
of the other contributors are responsible for any undesirable effects of using
this program. Also, none of the authors are responsible for the possesion or
use of any copyrighted material taken from copyrighted ROMs using this
program.
+++++++++++++++++
2.) License Rights
--------------------------------------------
- OpenSPC Program and Code - General
----------------------------------
Please do not redistribute either of these without their respective
documentation. Also, do not package them with either SPC or IT files from
copyrighted games.
- OpenSPC Code - Usage Rights
---------------------------
If you would like to modify the source to OpenSPC in some way, you may send
your version of it to the authors, who will choose whether to include your
improvements in future versions. Please do not make a change or improvement
and release your own, separate program. However, independent ports of
OpenSPC to other platforms are welcome, as long as you let the authors know
what you've done. If you would like to use some part of the source in a
program of your own design, you are free to do so, provided the primary
author is aware of what you are doing. Please give the author(s) credit for
any benefits you receive from either the direct use or the examination of this
code.
Blah, legal crap. :( I'm sure none of you out there will try to rip me off...
But please read and follow this section anyway.
+++++++++++++++++++
3.) Programming Conventions
--------------------------------------------
I have tried to make the source as uniform as possible, to make it easier to
read and understand. Also I have tried to comment wherever possible. What
follows is a list of different programming conventions used by me and which
should be used when modifying the source:
- Tab Spacing is 8
- if, for, and other bracketed statements should take the following form:
if(something)
{
//Do some stuff
//Do some more stuff
}
Here are some examples of what NOT to do:
if(something){/*Do some stuff*//*Do some
more stuff*/}
if(something)
{
//Do some stuff
//Do some more stuff
}
if(something){
//Do some stuff
//Do some more stuff
}
If there is only one statement within the brackets, they may be omitted.
However, the statement should be on the following line and tabbed once:
if(something)
//Do only one thing
- Global variables:
- Try to use them as little as possible
- When you do use them, define them in the .c file whose function they most
correspond with. If that .c file is the only one in the project that
needs that variable, define it as static. This goes for functions as
well.
- If a global variable must be seen outside the .c file it is defined in,
include it in the .h file associated with that .c file, and give it a name
that corresponds with that file. For example, any global variable you
will find in the sound.c file is preceded by the letters SND: SNDvoices,
SNDsamples, etc. This also goes for functions.
This is all I can think of right now. For the most part, just observe what
is already there and try to make your code look and work similarly.
++++++++++++++++
4.) Brief Outline
--------------------------------------------
What follows is a rough outline of how the program works:
- Startup: display message, read config file, parse command line
- Init the SPC: allocate memory, call SNEeSe's Reset command, then load in
registers from the input file
- Init the mixer: make up some tables, init some variables
- If in graphics mode, initialize allegro graphics and fader routine
- Init IT dump if capturing to an IT only
- Queue the notes that started when state was saved
- Initialize the Allegro sound stream to receive data from the mixer
- Main loop:
- Check to see whether Allegro wants more data
- If so, keep emulating and mixing until buffer is full
- Otherwise, render the display (if enabled)
- Dump the IT pattern buffers to disk if recording
- Check current time against time limit
- Check to see if we need to toggle voices or exit as a result of keypress
- Shut down stuff
- If dumping to an IT, figure out what the filename would be and save it.
- End program
Below is an explanation of the processing done when Allegro requests data,
found in the function SNDMix() in sound.c:
- Run the SNEeSe SPC
While this is going on, certain actions have been intercepted from SNEeSe
control:
- (new in v300) Timer control is now cycle-exact, and is handled by the
SNEeSe code.
- Reads and writes to the DSP are intercepted so as to return current sound
data and update sound data when something new is written.
- Control returns from the SNEeSe SPC when the number of cycles that should
have gone by in one update have been emulated.
(2048000 cycles / num_updates_per_second)
- Mixer then proceeds to process each of the 8 voices that are currently keyed
on. This includes updating the envelope, and detecting pitch and volume
changes so as to update the IT, as well as mixing the audio. It also
updates a global variable used by the display functions to determine the
current level of each voice and both channels.
- IT code writes the information recorded as having changed since the last
update. It must write it twice, once per each channel, left and right,
because the SPC has two independent volume controls rather than a volume and
a pan. (The display is somewhat faked... using that method to set the pan
doesn't result in a very good recording. Besides, as near as I can tell
volume and pan cannot be set simultaneously in an IT file.)
- Record IT end of row for this completed update. If we have filled a
pattern, use the next buffer. If no other buffer is available, the main
loop must be running too slow. Either way, simply overwrite the pattern we
just recorded since the data has to go SOMEWHERE. It will skip a pattern
though, so if this happens either turn down the sound quality in the config
file, or turn up NUM_PATT_BUFS in it.h.
- End of update, return from interrupt
I'm sure a lot of the mixer, envelope, and IT data stuff could use some
optimization; if you'd like to do it, as long as it doesn't lose any of the
current functionality I'll use it.
--Butcha