[Coco] tape format and .cas file problems

[Roger Taylor]

At 02:28 PM 11/19/2008, you wrote:
>On 11/19/08, Roger Taylor wrote:
> > At 08:38 AM 11/19/2008, you wrote:
> >
> >>So, could you come up with a client/server system where you CLOADM a
> >>small routine at 1MHz from the host PC which auto-executes, patches
> >>BASIC's cassette routine (assuming CoCo 3 or RAM-able 64K CoCo) for the
> >>faster protocol, and optionally switches the computer to 2MHz?  Then
> >>subsequent loads would zip.
> >
> >
> > Probably overkill.  Also, CLOADM only supports one start address as
> > far as I recall.  This means the entire ML program has to be
> > contiguous, unlike the multi-record LOADM format which can jump all
> > around RAM doing what it wants.
> >
> > I remember back in the 80's seeing Rainbow magazine ads selling CoCo
> > tricks like "Auto executing tape programs" but I could be wrong.  I'd
> > like to know how a lowly 16k or even 4k CoCo 1 could do this just by
> > typing CLOADM.  I don't see anything in the tape format that allows
> > for such a trick.
> >
>
>Roger,
>
>Color Basic does not support muti-segment CLOADM files, but Extended
>Basic does add that capability. These multi-segment files must have

Shows ya how much I clung to the tape format over the years.  I was 
under the impression that no CoCo ROM supported multi-segment 
CLOADMs, but I stand educated.  ;)

So, where are the origin control bytes in those data blocks?  The 
filename block has the initial load and exec addresses, ofcourse.


>the Gap Flag byte in the Name block set to "use gaps" instead of
>"contiguous" because the multi-segment loader calls CONSOLE IN to read
>one byte at a time from the file (like a data file).
>  The downside of
>this is that it takes much longer to read the file since there is an
>additional 0.5 seconds of silence and a series of sync bytes between
>every 255 bytes of data.

Exactly.  And on top of that, this gap probably needs to be 1 second 
long for ASCII BASIC listings *IF* no motor control is available like 
with my cocotape.exe program listening to the audio from the 
PC.  I've seen long BASIC listings choke down a CoCo for almost 2 
seconds before starting the next gapped block.  I'll obviously do 
lots of testing with that.


>One trick I've seen is to use this muti-segment format to load a few
>non-contiguous blocks at the beginning, including a segment that
>patches the RAM vector for the error handler and a final segment that
>loads a byte at address $FFFF. Since $FFFF can't be modified, that
>triggers an IO error which ends up calling the patched RAM vector
>which jumps to the CLOADM command again to load a normal (contiguous)
>file which immediately follows. This requires that no End-Of-File
>block be present for the first (multi-segment) file.

Makes sense.  The second entry into CLOADM otherwise would hear the 
EOF block from the previous set of blocks.


>By the way, I too have written a utility to convert CAS files to audio
>and vise-versa. However, mine currently works on Mac OS only and uses
>the AIFF audio file format (which is very similar to WAV).

I figured I could just throw that feature into cocotape.exe.  I can't 
find the .cas specs to see how the silence gaps are stored.  You 
can't represent silence as a byte that represents 8 sinewaves of 0 or 1.


-- 
Roger Taylor

http://www.wordofthedayonline.com