On Mon, Apr 06, 2009 at 06:05:03PM +0200, silverdr@wfmh.org.pl wrote:
> Ah, OK. The protocol is in fact a different beast and not really a  
> typical one. Here I believe Marko is the best to tell more about. I once 
> wrote "The Finaltape". A highly extended turbo based on other  
> implementations but I never really touched the original CBM  
> implementation. It was so inefficient that I never felt like even having 
> a closer look ;-)
>
>> There is this:
>>
>> http://www.zimmers.net/anonftp/pub/cbm/crossplatform/transfer/C2N232/firmware/c2n-format.txt
>>
>> But, I'm looking for an article or other reference that goes into more 
>> detail (read: the quick document above did not make sense to me)

The quick document attempts to be a formal grammar.  The alphabet is ABCD
(pause and three different pulse widths).  The encoding is slightly
different on the 264 series.  The c2n232 firmware actually sends the
letters A, B, C, D over the wire when you run c2n -d (decode).

Please have a look at the c2n source code.  That program will decode and
encode Commodore tape images (not to be confused with the file format
that was introduced by the C64S emulator).  Programs in the commodore
tape image format consist of a 192-byte header block (of which 16 bytes
will be displayed as the file name in a FOUND message) and an
arbitrary-length payload block.  Each block is sent twice.

With the c2n program, you can even convert tapes to PCM *.wav files,
record them on a normal audio tape deck, and load on the 1530 datasette.

The c2nload program loads the fastloader program in the 192-byte tape buffer
in the header block and loads a 2-byte payload that redirects the CHROUT
vector to the code in the tape buffer.  You could do even faster by omitting
the 2nd copy of the 2-byte block, but I didn't like a ?LOAD ERROR. :-)

> Yes. That was where everyone's interest was. The standard routines where 
> used only to bootstrap a "proper" (faster/more reliable) loader.

I wouldn't call the Commodore format unreliable.  I was able to resurrect
some old tapes in the Commodore format, because each block is set twice
and because there are three different pulse widths in use, as opposed to
two.  It's easy to detect byte boundaries.  To decode these broken tapes
(mostly BASIC programs), I wrote a Perl script to decode the pulse stream
and edited the binary in GNU Emacs.  With the likes of Turbo Tape (no
clear byte boundaries), this would have been hopeless.

If you want to see a slow format, try KIM-1. :-)  It's also supported by
the "c2n" program.

	Marko

       Message was sent through the cbm-hackers mailing list