Using sod2 on MS-DOS
--------------------

#ifdef POLITICS

Consider switching from MS-DOS to Linux or {Net,Free}BSD. Sod2 will be
a lot nicer and almost certainly quicker (which, frankly, applies to
just about *everything* relative to MS-DOG ;-)), and all three OS's are
free.

But I know you won't do that just to run this, so... :-)

#endif

To compile sod2 for MS-DOS, you need djgpp. [NB: I've only compiled
sod2 with djgpp 1.x. 2.x should work too, but it's untested.] It's
available on your local simtel mirror, and probably lots of other
places besides. (Personally, I got it off a CD-ROM. :-)) The main
simtel mirror (no longer just a mirror, of course) is oak.oakland.edu,
but that's usually a busy site, and there's likely to be a mirror
closer to you. For example, in the UK, there's ftp.doc.ic.ac.uk, which
has it under /pub/packages/simtel.

To compile, edit the Makefile by commenting out the BUF_FLAG line and
removing '-fomit-frame-pointer' from the CFLAGS line, do 'make' (which
will fail on tune_main.c, but don't worry about that) and then
'coff2exe sod2'. None of the support programs like tunesam etc. work
on MS-DOS yet, but sod2 works just fine.

Now, I've already implied this next point, but I'll make it clear
here: sod2 does not play the sample it creates itself, it relies on
you or the OS to sort that out. So while on Linux you can dump it to
/dev/dsp, and on SunOS you can pipe it through sox to /dev/audio, on
MS-DOS there's no OS support at all. You have to have it output to a
file, and then play that 'by hand'.

[Note to hackers: adding SB support might not be too hard if you have
a copy of the SB lib for djgpp (I only have a really old copy). Just
write your own fputc-like 'output a single byte' routine in sod2.c and
setup main() to point write_sample to it. You'll probably need to
buffer it (and possibly restructure 16-bit samples if you want to
support them), but that's hardly difficult.]

If you have the dos version of 'sox' (also available on simtel and
similar dos archives), and 'vplay' or some other .voc playing program,
then once the 'output' file is generated you could do something like
this:

	sox -t ub output output.voc
	vplay output.voc

This works for 8kHz mono 8-bit output. If you generated 16kHz stereo
16-bit output, change the 'sox' line to:

	sox -r 16000 -c 2 -t sw output output.voc

Note that you will need a potentially LARGE amount of disk space for
all this, and it won't be quick.

If you have enough disk space, and a disk-write-cache like smartdrv,
this shouldn't be all that painful. 

But, the big problem with sod2 on dos is filenames. The standard
sample set distributed with sod2 uses some sample names which are not
only longer than dos's 8.3, but don't form unique 8.3 filenames when
shortened. This restricts you to playing tar files (see the sod2 man
page) unless you hack the sample names and the references to them in
the csf files. Hopefully this'll be fixed eventually, but don't hold
your breath.

-Rus.
