home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / boo / boo-file.hints next >
Text File  |  2020-01-01  |  5KB  |  125 lines
  1. 11-Nov-87 11:01:04-EST,5187;000000000001
  2. Return-Path: <FDCCU@CUVMA.BITNET>
  3. Received: from CUVMA.COLUMBIA.EDU by CU20B.COLUMBIA.EDU with TCP; Wed 11 Nov 87 11:00:57-EST
  4. Received: from CUVMA.COLUMBIA.EDU(MAILER) by CUVMA.COLUMBIA.EDU(SMTP) ; Wed, 11 Nov 87 11:00:16 EST
  5. Received: by CUVMA (Mailer X1.25) id 3149; Wed, 11 Nov 87 11:00:12 EST
  6. Date: 11/11 10:47:32
  7. From: FDCCU@CUVMA
  8. Subject: BOO BWR - PUN file from RSCS
  9. Tag: FILE (4110) ORIGIN DBNUAMA1 RECK     11/11/87  6:05:41 E.S.T.
  10. To: SY.FDC@CU20B
  11. Reply-To: RECK%DBNUAMA1.BITNET@CUVMA.COLUMBIA.EDU
  12.  
  13. ****** CC for you, Frank ******
  14. By the way, I forgot: thanks very much for calling the admissions
  15. people! I think my friend Christoph hasn't got anything yet, but of
  16. course, ordinary mail is slow. Anyway, the delay has been accounted
  17. for, and he is much calmer now.
  18.  
  19.  
  20. From: RECK@DBNUAMA1.BITNET (Gisbert W.Selke)
  21. To:   PHIL@UIUCVMD (Phil Howard)
  22. Date: 11 Nov 87
  23. Re:   BOO file problems (cf. last info-kermit digest)
  24.  
  25.  
  26. No, I don't have the AMIGA Kermit, but:
  27. I was doubting my sanity some time ago when I had serious problems with
  28. MS-Kermit boo files, too. It turned out to be a local EBCDIC -> ASCII
  29. conversion problem, and after some experimenting I found a way to get
  30. my boo files transferred in a reliable way - the un-booed executables
  31. do work.
  32.  
  33. The problem is mainly that the boo format uses all the characters from
  34. ASCII-zero (ASCII 48) to ASCII-tilde (ASCII 126). Included in this set
  35. are some characters for which no standard EBCDIC <-> ASCII conversion
  36. rule exists; assuming that characters and digits are OK (they will be,
  37. won't they?!?), the extra characters needed are:
  38.  
  39. colon                 ":"
  40. semicolon             ";"
  41. less than             "<"
  42. equals                "="
  43. greater than          ">"
  44. question mark         "?"
  45. at-sign               "@"
  46. left  square bracket  "["  (at our place, EBCDIC hex 'AD')
  47. backslash             "\"
  48. right square bracket  "]"  (at our place, EBCDIC hex 'BD')
  49. caret, up-arrow       "^"  (in EBCDIC, usually negation sign)
  50. underscore            "_"
  51. accent grave          "`"
  52. left  curly brace     "{"
  53. vertical bar          ":"  (maybe "|" in some EBCDIC places)
  54. right curly brace     "}"
  55. tilde, quiggle        "~"
  56.  
  57. You should check if all these characters are transferred properly with
  58. whatever procedure you use to get files to your Amiga. The ones that
  59. caused trouble here were the up-arrow/negation-sign, the vertical bar
  60. and the square brackets. So I used XEDIT to translate these particular
  61. characters into inconspicuous sequences which got transferred properly;
  62. I wrote the following XEDIT macro file to accomplish this:
  63.  
  64. SET LRECL 255
  65. SET TRUNC 255
  66. SET ARB OFF
  67. SET HEX ON
  68. TOP
  69. * For transferring boo files to PC via IRMA board and IRMA software:
  70. * translate characters which will not transfer properly otherwise:
  71. :0 C /^/`not`/ * *
  72. :0 C /|/`vba`/ * *
  73. :0 C /X'AD'/`lbr`/ * *
  74. :0 C /X'BD'/`rbr`/ * *
  75.  
  76. Remember to invoke XEDIT with a greater width, i.e.
  77.            XEDIT  <file name>  <file type>  (width 255 noprof
  78. This also makes sure you're not hampered by any profile which sets
  79. trunc or lrecl to something inconvenient. Executing the above macro
  80. file results in a file with greater line lengths: your file transfer
  81. utility should be able to cope with that.
  82. Also note that at some places, apparently ASCII left and right square
  83. brackets are translated to EBCDIC "" (cent) and "|" (continuous
  84. vertical bar), respectively; you might have to check that, although
  85. I never encountered that with CUVMA files.
  86.  
  87. Well, I hope this at least gives you some clues, even if it isn't a
  88. ready solution to your problem.
  89.  
  90. Happy kermitting,
  91.  
  92. \Gisbert
  93.  
  94. P.S.: I am enclosing a brief description of the boo format which
  95. I prepared for a booing programme - for what it's worth.
  96.  
  97.  
  98. C     BOO FORMAT FILES
  99. ...
  100. C
  101. C     IT IS NOT MEANT TO BE A TRANSFER PROTOCOL REPLACEMENT; IT
  102. C     JUST MAKES TRANSFER POSSIBLE ACROSS LINES (E.G., DATA NETWORKS)
  103. C     WHEN NO KERMITS ARE AVAILABLE OR ONE OF THEM CAN'T COPE WITH
  104. C     BINARY STUFF.
  105. C
  106. C     BEWARE OF GREMLINS, THOUGH; ESPECIALLY EBCDIC <-> ASCII
  107. C     TRANSLATION MAY BE A PROBLEM FOR SOME OF THE CHARACTERS ...
  108. C
  109. C     BASICALLY, 3 BYTES = 24 BITS ARE ENCODED INTO 4 CHARACTERS
  110. C     BY DIVIDING THEM INTO 6-BIT-PIECES AND THEN ADDING ASCII-ZERO
  111. C     TO MAKE THESE PIECES PRINTABLE. THE RESULT LIES IN THE RANGE
  112. C     ASCII-ZERO TO ASCII-SMALL-O. - IN ADDITION, NULL COMPRESSION
  113. C     TAKES PLACE; CONSECUTIVE NULL BYTES (WHICH OCCUR FREQUENTLY
  114. C     IN EXECUTABLE FILES, E.G.) ARE ENCODED WITH A TILDE LEAD-IN
  115. C     FOLLOWED BY THE NUMBER OF NULLS (UP TO 78), AGAIN RENDERED
  116. C     PRINTABLE BY ADDING ASCII-ZERO. THE RESULTING CHARACTER IS IN
  117. C     THE RANGE ASCII-ZERO (WELL, ASCII-TWO OR -THREE, REALLY) TO
  118. C     TILDE (ASCII CODE 126). - CHUNKS OF FOUR CHARACTERS BELONGING
  119. C     TOGETHER (RSP. TILDE AND NULL REPEAT COUNT) SHOULD NOT BE
  120. C     DIVIDED ACROSS LINES. A LINE HAS A MAXIMUM LENGTH OF 76
  121. C     CHARACTERS. - IN ADDITION, THE FIRST LINE OF THE FILE CONTAINS
  122. C     THE NAME OF THE ORIGINAL FILE (IF KNOWN - OTHERWISE A DUMMY NAME)
  123. C     AND NOTHING ELSE.
  124. C
  125.