[Coco] .CAS file format

Gustavo Ranaur Schoenaker ranaur at ranaur.net
Mon Dec 17 08:03:57 EST 2012


Well ... I'm proud to tell that the first version of the reader (in Octave)
worked yesterday. The CAS writting routine was easy ... just one hexdump
showed me how it works. It's just a bit bucket. :)

The first converted file was a basic program I wrote to print a MERP
Character Sheet in 1990. I used to pay a lot of RPGs those times. :)

It's painful slow and uses a lot of memory. I left it to process a 1-hour
record and it took more than 7 hours. I left it running and went to work.
Actually I know that I need to make it more memory friendly. Octave is
*not* memory friendly. It uses everything in memory, so a full 1-hour tape
takes about 1 GB of RAM just for the wave file. The funny part is that no
program is bigger than 64K. :)

Well .. I'll optime it to handle big files gracefully. It is easy cake to
do. The first thing was making a proof of concept. Now I go on the
otimizations.

As soon as I fix this memory hog, are anyone interested? Please reply, so I
can write a decent documentation. Reading a tape is quite simple (just call
a coupe of functions). But the best part is to inspect the tape data in the
memory before writing the CAS file, and to do that you'll need to
understand a little bit of the internals.

The good part that is is open source (if you can get rich with this, you
are a genius! :) and runs on everything that can run a Matlab/Octave e.g.
everything that was build after 2000.

Bye!

On Mon, Dec 17, 2012 at 6:14 AM, Ciaran Anscomb <cocomalt at 6809.org.uk>wrote:

> Robert Gault wrote:
> > Bill Pierce wrote:
> >
> > > I thought the "cas" format was just a special wav format, not a "byte
> by
> > > byte" storage format?
> >
> > > From: Luis Antoniosi <retrocanada76 at gmail.com>
> > > >
> > > is byte-by-byte. Open it in an hex editor and you will see.
> >
> > I'm glad this came up as a topic, because you are both right! This may
> also
> > explain some of the problems users of emulators may be having. It won't
> > explain the errors many files produce when converted from Coco tapes to
> sound
> > files.
> >
> > VCC uses a fake cassette format for CSAVE which has a header of 128
> bytes of
> > $55, a file name with some special characters, 128 bytes of $55, and
> then the
> > tokenized Basic program. MESS uses a sound file which emulates a cassette
> > file. The CSAVE file is a RIFF , Windows PCM, 44.1kHz, 16-bit mono.
>
> Think of each 0 bit as a cycle of 1200Hz and each 1 bit as a cycle
> of 2400Hz (kinda - I actually think they get written closer to 1100Hz
> and 2100Hz).  Read out bytes lowest bit first.
>
> The various tools (including XRoar in -tape-rewrite mode) will try and
> keep the bytes in the CAS file synchronised with bytes in memory (for
> readability in hex editors!), but there's no reason they have to be.
>
> The simplicity of the format also means CAS can't represent different
> pulse widths (well, you could make your emulator observe BASIC's idea
> of expected pulse width and simulate that, but that wouldn't work for
> custom loaders).
>
> FWIW I've often thought it would be nice to extend CAS to be able to
> represent different pulse widths, raw audio, etc. in the same way as
> TZX as used in the Spectrum emulator world.  You could make command
> bytes of $55 or $AA indicate "normal CAS data until end of tape", thus
> keeping a measure of backwards compatibility...
>
> ..ciaran
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> http://five.pairlist.net/mailman/listinfo/coco
>



More information about the Coco mailing list