On Mon, Apr 06, 2009 at 06:05:03PM +0200, firstname.lastname@example.org 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 listReceived on 2009-04-06 22:41:30
Archive generated by hypermail 2.2.0.