Use this forum to submit new files for the download section of the archive. I will check each submission and upload it to the archive on a regular basis.
usage: bin2cas OPTION... input-file
bin2cas --blocks TYPE:LENGTH[,TYPE:LENGTH]... input-file
Generate a cassette image from binary input.
-D input file is a DragonDOS binary
-C input file is a CoCo RSDOS binary
-l ADDR load address in filename block
-e ADDR exec address in filename block
-n NAME name in filename block
-o FILE output file (defaults to stdout)
--leader COUNT leader size before filename block and data
--no-filename no filename block required in output
--no-eof no EOF block required in output
--eof-data EOF block allowed to contain the last chunk of data
--wav-out output a WAV file instead of a CAS
-r, --wav-rate RATE sample rate for WAV output
In standard cassette image mode, load and exec addresses are determined from
the binary if DragonDOS or RSDOS binary format is specified, otherwise they
should be specified as an option.
With --blocks, each block TYPE and LENGTH is explicitly specified. If LENGTH
is negative, this means "use all but the last -LENGTH bytes". If TYPE is the
character "l", a leader of LENGTH bytes is emitted.
usage: bin2cas OPTION... input-file
bin2cas --blocks [l | p | TYPE:LENGTH]... input-file
Generate a cassette image from binary input.
-B input file is raw binary (default)
-D input file is a DragonDOS binary
-C input file is a CoCo RSDOS binary
-l ADDR load address in filename block
-e ADDR exec address in filename block
-n NAME name in filename block
-o FILE output file (defaults to stdout)
--leader COUNT leader size before filename block and data
--no-filename no filename block required in output
--no-eof no EOF block required in output
--eof-data EOF block allowed to contain the last chunk of data
--wav-out output a WAV file instead of a CAS
-r, --wav-rate RATE sample rate for WAV output
In standard cassette image mode, load and exec addresses are determined from
the binary if DragonDOS or RSDOS binary format is specified, otherwise they
should be specified as an option.
The argument to --blocks is a comma-separated list of instructions:
l emit a leader
p emit a ~0.5s pause (wav), or leader (cas)
TYPE:LENGTH emit block of specified type and length from input. If LENGTH
is negative, use all but the last -LENGTH bytes from the input.
usage: bin2cas OPTION... input-file
bin2cas --blocks [l | p | TYPE:LENGTH]... input-file
Generate a cassette image from binary input.
-B input file is raw binary (default)
-D input file is a DragonDOS binary
-C input file is a CoCo RSDOS binary
-l ADDR load address in filename block
-e ADDR exec address in filename block
-n NAME name in filename block
-o FILE output file (defaults to stdout)
--leader COUNT leader size before filename block and data
--no-filename no filename block required in output
--no-eof no EOF block required in output
--eof-data EOF block allowed to contain the last chunk of data
--wav-out output a WAV file instead of a CAS
-r, --wav-rate RATE sample rate for WAV output
--dzip pipe file input through dzip
--dunzip autorun header with dunzip (implies --dzip)
In standard cassette image mode, load and exec addresses are determined from
the binary if DragonDOS or RSDOS binary format is specified, otherwise they
should be specified as an option.
The argument to --blocks is a comma-separated list of instructions:
l emit a leader
p emit a ~0.5s pause (wav), or leader (cas)
TYPE:LENGTH emit block of specified type and length from input. If LENGTH
is negative, use all but the last -LENGTH bytes from the input.
Does the call out to dzip work ok in Windows then? I was paranoid that my use of open2() wasn't exactly safe, so have updated it again to use a forking technique.
Edit: if you want to test, here is a dzip executable (built using mman-win32) - should just be a case of dropping it your PATH somewhere.
usage: bin2cas OPTION... input-file
bin2cas --blocks [l | p | TYPE:LENGTH]... input-file
Generate a cassette image from binary input.
-B input file is raw binary (default)
-D input file is a DragonDOS binary
-C input file is a CoCo RSDOS binary
-l ADDR load address in filename block
-e ADDR exec address in filename block
-n NAME name in filename block
-o FILE output file (defaults to stdout)
--leader COUNT leader size before filename block and data
--no-filename no filename block required in output
--no-eof no EOF block required in output
--eof-data EOF block allowed to contain the last chunk of data
--wav-out output a WAV file instead of a CAS
-r, --wav-rate RATE sample rate for WAV output
--dzip pipe file input through dzip
--dunzip autorun header with dunzip (implies --dzip)
In standard cassette image mode, load and exec addresses are determined from
the binary if DragonDOS or RSDOS binary format is specified, otherwise they
should be specified as an option.
The argument to --blocks is a comma-separated list of instructions:
l emit a leader
p emit a ~0.5s pause (wav), or leader (cas)
TYPE:LENGTH emit block of specified type and length from input. If LENGTH
is negative, use all but the last -LENGTH bytes from the input.
# bin2cas.pl - convert a raw/DragonDOS/CoCo binary into a .cas or .wav file.
# Ciaran Anscomb, 2011-2014. Public Domain.
# See the output of "bin2cas.pl --help" for detailed usage information, with
# examples.
# v3.0: complete overhaul
# supports multiple parts
# builds reasonably arbitrary autorun loader
# update VDG & SAM configs during loading
# manual cursor flasher for when video offset changed
# v3.0a: tweak default samplerate to 12kHz if fast mode used
# slightly increase speed in fast mode
usage: ./bin2cas.pl [OPTION]... input-file [[OPTION]... input-file]...
Generate a cassette image from binary input.
Output file options:
-o, --output FILE output filename
--cas write CAS file
--wav write WAV file
-r, --wav-rate RATE sample rate in Hz for WAV output [9600]
Data options:
-B following files are raw binary (default)
-D following files are DragonDOS binary
-C following files are CoCo RSDOS binary
--leader COUNT leader size before filename block and data
--no-filename no filename block required
-n, --name NAME name in filename block
-l, --load ADDR load address of next file
-e, --exec ADDR exec address of next file or to autorun
--zload ADDR override automatic load address for dzipped file
-z, --dzip dzip following files (adds dunzip to autorun)
--fast write following files 33% faster (WAV only)
--eof-data EOF block allowed to contain data (non-standard)
--no-eof don't emit EOF block for following files
--no-dzip don't dzip following files (default)
--no-fast following files written at normal speed (default)
--no-eof-data EOF block not allowed to contain data (default)
--eof do emit EOF block for following files (default)
-i FILE specify input file (e.g., if it begins with a "-")
Autorun specific options:
--autorun build a single autorunning program
--vdg MODE set VDG mode before next file
--sam-v V set SAM VDG mode (0-7, see SAM docs)
--sam-f F set SAM display offset to F * 512
--flasher manual cursor flasher enabled for next file
Without --autorun, each input file is written with its own filename block.
If --autorun is specified, all files are considered to be part of one
autorunning program. Data options will apply to the next input file, and
instructions added to the autorun code where appropriate. The last file
determines the EXEC address (unless specified). Note: specify --autorun before
any input files.
The --flasher option is for use when the SAM display offset has been changed,
e.g., during a custom loading screen. The ROM routine will continue to flash
$0400, but this will not be visible, so this adds code to do it manually.
To compress data, the "dzip" tool is required to be in your PATH.
Compressed data can be unzipped "in place", so long as one extra byte is
allowed beyond the end of the original data, so the load address for dzipped
data is calculated as (original load address + original file size + 1 - zipped
file size). Sometimes that extra byte strays somewhere inconvenient, so this
calculated address can be overridden with the --zload option. e.g., the extra
byte beyond a text loading screen strays into DOS workspace ($0600), so
"--zload 0x0e00" would ensure the zipped data was loaded beyond it (also,
usefully, the end user then doesn't get to *see* the zipped data).
Simple example:
./bin2cas.pl -o game.cas -D game.bin
Builds a non-autorunning CAS file from the DragonDOS binary "game.bin".
Load & exec addresses taken from the input binary.
Complex example:
./bin2cas.pl --autorun -r 22050 -o game.wav --eof-data --dzip --fast \
-B --load 0x0e00 screen.bin \
--vdg 8 --sam-v 4 --sam-f 7 \
-C --flasher game.bin
Builds an autorunning 22kHz WAV file with two parts - a loading screen and the
main game. Each part is dzipped, and a small amount of space is saved by
combining the last data block with the EOF indicator. Each part is written
using shorter cycles - 33% faster than usual.
The loading screen data is a raw binary, so the load address is specified.
Once the screen has been loaded (and dunzipped into place), the VDG is put into
alpha/semigraphics mode with CSS 1, the SAM is configured to G3C (these two
combined configure Semigraphics 12 mode), and the SAM display offset set to
$0e00.
The game code is taken from a CoCo RSDOS (DECB) binary which contains load and
exec information. Extra cursor flashing code is added to the autorunner, as
the display offset is no longer $0400. As the last input file, its exec
address is used to autorun once loading is complete.
# bin2cas.pl - convert binary data to CAS or WAV with optional autorun
# Copyright (C) 2014 Ciaran Anscomb
# License: GNU GPL version 3 or later <http://www.gnu.org/licenses/gpl-3.0.html>.
# This is free software: you are free to change and redistribute it.
# There is NO WARRANTY, to the extent permitted by law.
#
# Special exception: Code included in output (such as "dunzip") is not
# considered to be part of this program, so the GPL doesn't apply to the
# results.
# See the output of "bin2cas --help" for detailed usage information, with
# examples.
# v3.1: default timing uses varying pulse widths to account for ROM delays
# --timing option selects between "rom" and "simple" timing
# fast cycle timing better at 9600Hz, so dropped default back
# slightly faster WAV creation by caching runs of samples
# v3.2: don't redirect STDOUT
# new option --lds inserts stack adjustment code into autorun
# license foo, --version
usage: ./bin2cas [OPTION]... input-file [[OPTION]... input-file]...
Convert binary data to CAS or WAV with optional autorun.
Output file options:
-o, --output FILE output filename (required)
--cas write CAS file
--wav write WAV file
-r, --wav-rate RATE sample rate in Hz for WAV output [9600]
-t, --timing NAME select timing spec (rom or simple) [rom]
Data options:
-B following files are raw binary (default)
-D following files are DragonDOS binary
-C following files are CoCo RSDOS binary
--leader COUNT leader size before filename block and data
--no-filename no filename block required
-n, --name NAME name in filename block
-l, --load ADDR load address of next file
-e, --exec ADDR exec address of next file or to autorun
--zload ADDR override automatic load address for dzipped file
-z, --dzip dzip following files (adds dunzip to autorun)
--fast write following files 30% faster (WAV only)
--eof-data EOF block allowed to contain data (non-standard)
--no-eof don't emit EOF block for following files
--no-dzip don't dzip following files (default)
--no-fast following files written at normal speed (default)
--no-eof-data EOF block not allowed to contain data (default)
--eof do emit EOF block for following files (default)
-i FILE specify input file (e.g., if it begins with a "-")
Autorun specific options:
--autorun build a single autorunning program
--vdg MODE set VDG mode before next file
--sam-v V set SAM VDG mode (0-7, see SAM docs)
--sam-f F set SAM display offset to F * 512
--lds S set the stack pointer
--flasher manual cursor flasher enabled for next file
Other options:
--help show this help
--version show program version
The default sample rate for WAV output is 9600Hz, and this has been shown to
survive speed variations well when loading on real hardware while keeping file
size to a minimum. However, if you are going to write the output to tape, it
is highly recommended that you specify a higher rate, e.g., with "-r 48000".
Without --autorun, each input file is written with its own filename block.
If --autorun is specified, all files are considered to be part of one
autorunning program. Data options will apply to the next input file, and
instructions added to the autorun code where appropriate. The last file
determines the EXEC address (unless specified). Note: specify --autorun before
any input files.
The --flasher option is for use when the SAM display offset has been changed,
e.g., during a custom loading screen. The ROM routine will continue to flash
$0400, but this will not be visible, so this adds code to do it manually.
Normally the stack pointer is left at the top of BASIC. Use the --lds option
to adjust it at any point.
To compress data, the "dzip" tool is required to be in your PATH.
Compressed data can be unzipped "in place", so long as one extra byte is
allowed beyond the end of the original data, so the load address for dzipped
data is calculated as (original load address + original file size + 1 - zipped
file size). Sometimes that extra byte strays somewhere inconvenient, so this
calculated address can be overridden with the --zload option. e.g., the extra
byte beyond a text loading screen encroaches into DOS workspace ($0600), so
"--zload 0x0e00" would ensure the zipped data was loaded beyond it (also,
usefully, the end user then doesn't get to *see* the zipped data loading).
The default timing spec ("rom") accounts for the slight variations of delay in
the Dragon ROM before it starts to count a pulse width. The "simple" timing
spec is closer to the output of CSAVE.
Simple example:
./bin2cas.pl -o game.cas -D game.bin
Builds a non-autorunning CAS file from the DragonDOS binary "game.bin".
Load & exec addresses taken from the input binary.
Complex example:
./bin2cas.pl --autorun -r 22050 -o game.wav --eof-data --dzip --fast \
-B --load 0x0e00 screen.bin \
--vdg 8 --sam-v 4 --sam-f 7 \
-C --flasher game.bin
Builds an autorunning 22kHz WAV file with two parts - a loading screen and the
main game. Each part is dzipped, and a small amount of space is saved by
combining the last data block with the EOF indicator. Each part is written
using shorter cycles - just over 30% faster than usual.
The loading screen data is a raw binary, so the load address is specified.
Once the screen has been loaded (and dunzipped into place), the VDG is put into
alpha/semigraphics mode with CSS 1, the SAM is configured to G3C (these two
combined configure Semigraphics 12 mode), and the SAM display offset set to
$0e00.
The game code is taken from a CoCo RSDOS (DECB) binary which contains load and
exec information. Extra cursor flashing code is added to the autorunner, as
the display offset is no longer $0400. As the last input file, its exec
address is used to autorun once loading is complete.
# bin2cas.pl - convert binary data to CAS or WAV with optional autorun
# Copyright (C) 2014 Ciaran Anscomb
# License: GNU GPL version 3 or later <http://www.gnu.org/licenses/gpl-3.0.html>.
# This is free software: you are free to change and redistribute it.
# There is NO WARRANTY, to the extent permitted by law.
#
# Special exception: Code included in output (such as "dunzip") is not
# considered to be part of this program, so the GPL doesn't apply to the
# results.
# See the output of "bin2cas --help" for detailed usage information, with
# examples.
# v3.1: default timing uses varying pulse widths to account for ROM delays
# --timing option selects between "rom" and "simple" timing
# fast cycle timing better at 9600Hz, so dropped default back
# slightly faster WAV creation by caching runs of samples
# v3.2: don't redirect STDOUT
# new option --lds inserts stack adjustment code into autorun
# license foo, --version
# v3.3: actually drop default to 9600Hz
# dzip using temp files under windows
usage: ./bin2cas [OPTION]... input-file [[OPTION]... input-file]...
Convert binary data to CAS or WAV with optional autorun.
Output file options:
-o, --output FILE output filename (required)
--cas write CAS file
--wav write WAV file
-r, --wav-rate RATE sample rate in Hz for WAV output [9600]
-t, --timing NAME select timing spec (rom or simple) [rom]
Data options:
-B following files are raw binary (default)
-D following files are DragonDOS binary
-C following files are CoCo RSDOS binary
--leader COUNT leader size before filename block and data
--no-filename no filename block required
-n, --name NAME name in filename block
-l, --load ADDR load address of next file
-e, --exec ADDR exec address of next file or to autorun
--zload ADDR override automatic load address for dzipped file
-z, --dzip dzip following files (adds dunzip to autorun)
--fast write following files 30% faster (WAV only)
--eof-data EOF block allowed to contain data (non-standard)
--no-eof don't emit EOF block for following files
--no-dzip don't dzip following files (default)
--no-fast following files written at normal speed (default)
--no-eof-data EOF block not allowed to contain data (default)
--eof do emit EOF block for following files (default)
-i FILE specify input file (e.g., if it begins with a "-")
Autorun specific options:
--autorun build a single autorunning program
--vdg MODE set VDG mode before next file
--sam-v V set SAM VDG mode (0-7, see SAM docs)
--sam-f F set SAM display offset to F * 512
--lds S set the stack pointer
--flasher manual cursor flasher enabled for next file
Other options:
--help show this help
--version show program version
The default sample rate for WAV output is 9600Hz, and this has been shown to
survive speed variations well when loading on real hardware while keeping file
size to a minimum. However, if you are going to write the output to tape, it
is highly recommended that you specify a higher rate, e.g., with "-r 48000".
Without --autorun, each input file is written with its own filename block.
If --autorun is specified, all files are considered to be part of one
autorunning program. Data options will apply to the next input file, and
instructions added to the autorun code where appropriate. The last file
determines the EXEC address (unless specified). Note: specify --autorun before
any input files.
The --flasher option is for use when the SAM display offset has been changed,
e.g., during a custom loading screen. The ROM routine will continue to flash
$0400, but this will not be visible, so this adds code to do it manually.
Normally the stack pointer is left at the top of BASIC. Use the --lds option
to adjust it at any point.
To compress data, the "dzip" tool is required to be in your PATH.
Compressed data can be unzipped "in place", so long as one extra byte is
allowed beyond the end of the original data, so the load address for dzipped
data is calculated as (original load address + original file size + 1 - zipped
file size). Sometimes that extra byte strays somewhere inconvenient, so this
calculated address can be overridden with the --zload option. e.g., the extra
byte beyond a text loading screen encroaches into DOS workspace ($0600), so
"--zload 0x0e00" would ensure the zipped data was loaded beyond it (also,
usefully, the end user then doesn't get to *see* the zipped data loading).
The default timing spec ("rom") accounts for the slight variations of delay in
the Dragon ROM before it starts to count a pulse width. The "simple" timing
spec is closer to the output of CSAVE.
Simple example:
./bin2cas.pl -o game.cas -D game.bin
Builds a non-autorunning CAS file from the DragonDOS binary "game.bin".
Load & exec addresses taken from the input binary.
Complex example:
./bin2cas.pl --autorun -r 22050 -o game.wav --eof-data --dzip --fast \
-B --load 0x0e00 screen.bin \
--vdg 8 --sam-v 4 --sam-f 7 \
-C --flasher game.bin
Builds an autorunning 22kHz WAV file with two parts - a loading screen and the
main game. Each part is dzipped, and a small amount of space is saved by
combining the last data block with the EOF indicator. Each part is written
using shorter cycles - just over 30% faster than usual.
The loading screen data is a raw binary, so the load address is specified.
Once the screen has been loaded (and dunzipped into place), the VDG is put into
alpha/semigraphics mode with CSS 1, the SAM is configured to G3C (these two
combined configure Semigraphics 12 mode), and the SAM display offset set to
$0e00.
The game code is taken from a CoCo RSDOS (DECB) binary which contains load and
exec information. Extra cursor flashing code is added to the autorunner, as
the display offset is no longer $0400. As the last input file, its exec
address is used to autorun once loading is complete.
