[GreenKeys] RTTY Art JAVA Viewer Facelift

[William Bytheway]

Bob (KB8TQ),

Thanks for your thoughts, here are a few of my own to add to the coffers:

I don't favor the "straight binary map 5-bit to 8-bit" (with special
encoding rules) idea because it would require a special reader to just look
a the picture.  Archived files would be lost over time because it would not
be compatible with any COTS text viewers. We have no way of documenting the
RFC or interface design for future generations.

The RTTYArt software retains all of the "original" input without any
rewriting of the "cr" and "lf" sequences.  With POX files (pictures with
overstrike), you might see several "cr/data/cr/data" sequences without a
"lf" character.  On many tapes there is a "cr/cr/lf" trio was used just to
ensure that the carriage returned in just enough time for the old Model 19
to overstrike the current line.

My vote is a "pure" Baudot to ASCII conversion retaining all of the original
"cr" and "lf" sequences that were generated by the authors in the ~1970's.
Mapping of the original Baudot code to ASCII will retain all of the
"original" picture. Software for doing this is on my Web site.

Using a "standard text editor" to repair a Baudot picture is forbidden!
Depending on the operating system; Windows, DOS, VMS, OS2, Unix; the "cr"
and "lf" sequence can be completely different. The Unix, Dos, Windows, VMS
and Apple operating systems all use different "cr" and "lf" orders.  Editing
and saving a file on one of these operating systems re-writes the "cr/lf"
sequence, thus destroying the original picture.

73,
Bill Bytheway
K7TTY

-----Original Message-----
From: Bob Camp [mailto:ham at cq.nu]
Sent: Tuesday, January 18, 2005 6:06 PM
To: John Foust; Greenkeys ((E-mail))
Cc: William Bytheway
Subject: Re: [GreenKeys] RTTY Art JAVA Viewer Facelift


Hi

I spent some time thinking about this at work today and looking at an
ASCII table. I came up with a couple of things:

1) If we straight map the 5 level to 8 level (low bit to low bit) then
the 5 level all shows up in the first column of ASCII where all the
control characters are.

2) If you want to put headers on this stuff feeding it into a text
editor would be a nice thing.

3) If we use another column of ASCII for the map then we have no cr's
or lf's in the data stream. That's good because lf's won't get added to
cr's. It's bad because the lines will look like they are way long and
the editor will puke.

So here's my proposal:

1) Map the 5 level to the column of ASCII that begins with the @ sign
and contains all the capital letters. Do a straight bit for bit map
rather than character translations.

2) Break up the translated 5 level with an ASCII cr/lf pair every > 64
and < 72 characters. Obviously a short line would be fine since the
picture files will never be an exact number of lines long.

3) Use an ascii # to start any line that does not contain 5 level data

4) Start out the file with #Format 1 cr/lf  in ASCII

5) Finish the file with a #End

To interpret the file you would simply strip out anything that is not
in the proper ASCII column. You would also throw out any line that
starts with a #. That's simple enough that you could feed this file
into a PIC and have it re-transmit it as 5 level while running off of a
32KHz watch crystal.

I realize this is getting a little complex. It may be more complex than
necessary. The whole idea is to be able to work on a file with a
conventional text editor like notepad or nano. That way we can fix
damaged tapes without a lot of hassle. Writing an editor just to put
comments on the file sounds like a major hassle.

Any thoughts?

		Bob Camp
		KB8TQ