[GreenKeys] RTTY Art JAVA Viewer Facelift

[Bob Camp]

Hi

Maybe I'm missing something here. To say the least it would not be the 
first time.

If we take five level code and save it as eight level code then we have 
an extra three bits to fill up.

If we set them to all zeros then that's fine, but it eliminates 
handling the file as anything other than a binary file. That's ok but 
if it's binary then you don't get any comments or added notes.

One possibility would be to write a "stripper" program (maybe in Java) 
to take a commented file in and put a "binary" file out. I have a nasty 
suspicion that my "room full of tape" won't fill all that much disk 
space. I'm thinking back to loading PDP-8's and PDP-11's off of paper 
tape. You could load a couple of trays of tape into a 4K machine....  
Saving the files in several formats is not out of the question. Good 
old Comp USA is selling blank DVD's for 25 cents a piece. I suspect 
that saving all of the tapes in three or four formats will still be 
under one DVD.

Every time I have ever played with tapes before there has been a need 
to patch up the result. I won't say that it is sure to be true this 
time but it has been in the past. Binary editors are always a bit of a 
pain to work with. I can do it, but most people freak out a bit working 
on this kind of thing in hex.

I hoping that what ever we come up with will be of general use. If it's 
just a thing that four of five of us understand then that's bad. I'm 
not totally sure that straight binary is the best way to do that. Who 
knows ....

	Enjoy!

		Bob Camp
		KB8TQ



On Jan 19, 2005, at 1:55 AM, William Bytheway wrote:

> 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
>
>