home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / archives / k12.tar.Z / k12.tar / k12mit.not < prev    next >
Internet Message Format  |  1992-07-12  |  28KB

  1. Date:   7/11/92 15:00 EDT
  2. From:   Charles Lasner (lasner@watsun.cc.columbia.edu)
  3. To:     pdp8-lovers@ai.mit.edu
  4. Subj:   Announcement of new Kermit-12 utilities
  5.  
  6.     Currently available at watsun.cc.columbia.edu via ftp in
  7. /pub/ftp/kermit/d/k12*.* are two new files: k12enc.pal and
  8. k12dec.pal.  The new files have internal dates of 8-Jul-92.  Several
  9. other documentation files with similar dates are also available.
  10. Anyone who last retrieved Kermit-12 files prior to Feb, 1992 should
  11. retrieve much of the current collection which has changed since then.
  12.  
  13.     These are the newly updated ENCODE and DECODE programs for moving
  14. around OS/8 binary files in a reliable manner.  There is several new
  15. feature added to both:  the ability to deal with "raw" image data
  16. sent as a single file, and also sent split into two files.  Consider
  17. the following usage:
  18.  
  19. .R ENCODE
  20. *BIGGY.EN<RXA1:/I=756
  21.  
  22. When the input specification is a device only AND the /I switch is
  23. given AND a non-zero equals parameter is given (and neither /1 nor /2
  24. are given; see below), then the ENCODEd file is created containing
  25. the entire logical device for the length specified in the equals
  26. parameter.  In the example, the length of an RX01 in OS/8 terms is
  27. used.
  28.  
  29.     Note that the device need not be an OS/8 "legal" structure, and
  30. there is no individual input file significence either.  The user must
  31. set the length to whatever is appropriate.  Too large a number could
  32. result in program abort due to handler-reported input error.  The
  33. minimum length is 1; a zero-value is the same as leaving out the
  34. parameter.  (This is a restriction of OS/8 itself.)  Input data
  35. always starts at OS/8 logical record 0000.
  36.  
  37.     Note that the device must be definable within the scope of the
  38. selected OS/8 handler itself, since it is used for all input I/O
  39. using "raw" sequential calls.
  40.  
  41.     For example, an OS/8 bootable RX01 standard-format diskette would
  42. be acceptable for encoding here, while a WPS document disk would not
  43. be.  The reason is that the handler does not access track zero (not a
  44. WPS issue) and also does all reads in 12-bit mode, while WPS
  45. documents are written in 8-bit mode, portions of which are lost when
  46. using a 12-bit mode handler.
  47.  
  48.     By using another (user-written) handler that supplies 8-bit
  49. transfers, the WPS document disk CAN be successfully transferred to
  50. ENCODE format intact.  (Note: there are no current 8-bit mode
  51. handlers for RX02 and RX50, just RX01; this is a separate problem
  52. being addressed elsewhere.)
  53.  
  54.     Output DECODing is accomplished in a symmetrical manner:
  55.  
  56. .R DECODE
  57. *RXA1:<BIGGY.EN/I=756
  58.  
  59. When used in this manner, the equals parameter need not be exact, but
  60. must be at least as large as the parameter used when encoding.  A
  61. smaller value can be used to limit the transfer deliberately where
  62. appropriate.  For example, using =7 will only transfer the first
  63. seven records of the ENCODEd file onto the target device.  If the
  64. ENCODEd file contains a valid OS/8 device in complete image form,
  65. this amount will suffice to transfer only the directory to the target
  66. device.  This effectively aborts the transfer, so the user can look
  67. at the directory with DIR, etc., to determine suitability of the
  68. larger transfer, etc.
  69.  
  70. Warning:
  71.  
  72.     This usage writes over the output device starting at logical
  73. record 0000 (or higher; see below).  The (possibly present) previous
  74. OS/8 structure will be destroyed.  This is the intended function of
  75. this usage as the new data is meant to be moved to the beginning of
  76. an empty device.
  77.  
  78. Image splitting:
  79.  
  80.     As pointed out by a user, if the only device available on a PDP-8
  81. system is being used to acquire an image copy of the media, then this
  82. is likely to be impossible to carry out.  This is the case in some
  83. systems whose only disk device is a pair of RX01, or RX02, or RX50 in
  84. the case of the DECmates.
  85.  
  86.     The reason is that the image of a device is likely to be larger
  87. (as an ENCODEd file) than the OS/8 capacity of the device itself!
  88. Since the repeat-compression of the encoding process isn't a reliable
  89. phenomena (it's data-dependent), it is likely that some disk-image
  90. files will be too large.  Of course, if less than an entire device
  91. need be transferred, the equals parameter could be set to a shorter
  92. value where appropriate, but this prevents a complete transfer.
  93. (Alternatively, the data should be placed on a disk where the unused
  94. space has a repetitive pattern, such as that left after a format
  95. operation, or all zeroes, etc.  This would allow the
  96. repeat-compression of the ENCODE process to reduce these areas to
  97. insignificent quantities in the ENCODEd file.)  Of course, this still
  98. doesn't address the problem of sending an entire device, such as a
  99. fully-loaded diskette.
  100.  
  101.     To solve this problem, an additional option has been implemented
  102. to split the data into two nearly equal parts before encoding.
  103. Assuming the worst case of no repeat compression optimization, the
  104. ENCODEd image file representing half of the target disk data should
  105. fit on a bootable OS/8 disk.  This disk would only contain the system
  106. head, the DECODE.SV program, and the ENCODEd data file.  From this
  107. minimal system, the data can be written to another drive.  Then the
  108. entire process can be repeated using a similar disk containing
  109. instead the second-half ENCODEd file.  (There is no hope for a
  110. machine with only one disk!)
  111.  
  112.     Assuming our original RX01 example again:
  113.  
  114. .R ENCODE
  115. *BIGGY1.EN<RXA1:/I/1=756
  116. *BIGGY2.EN<RXA1:/I/2=756
  117.  
  118. This creates two image encoding files, each containing half of the
  119. device image.  (In the case of an odd size, the second half is one
  120. longer than the first half.)  Note that the size must be stated
  121. exactly so that the proper split occurs.
  122.  
  123. .R DECODE
  124. *RXA1:<BIGGY1.EN/I/1=756
  125. *RXA1:<BIGGY2.EN/I/2=756
  126.  
  127. This creates the disk image from the ENCODEd files.  Note that the
  128. size must be stated exactly as it was when the original files were
  129. created so that both the length and position of the files (especially
  130. the second-half file) are correct.
  131.  
  132.     To aid in restoration of the disk, the (FILE statement within the
  133. ENCODEd file indicates that it is a block-image file, not an
  134. individual file with a file name.  Additionally, the =xxxx value used
  135. to create the file is given to guide the decoding process.  If the
  136. ENCODEd files are split files, then it is further indicated that the
  137. file is a first-half or second-half of an image file as necessary.
  138.  
  139.     As of this version (2.1), the ENCODE program also inserts a
  140. (REMARK indicating the program version and other useful information.
  141.  
  142.     Overall program operation for all other operations remains
  143. unchanged.  As before, program documentation is contained in the
  144. source files.  Except for the new image transfer features, the
  145. programs are totally compatible with their previous respective
  146. versions.  (Note, the latest and previous versions are NOT compatible
  147. with the original "ancient" version which was "provisionally"
  148. released while the encoding format was still being formulated!  Thus,
  149. there is one incompatible original version, and all following
  150. versions are compatible except for added features.)
  151.  
  152. cjl
  153.  
  154. ------------------------------
  155. Date:   3/11/92 00:48 EST
  156. From:   Charles Lasner (lasner@watsun.cc.columbia.edu)
  157. To:     pdp8-lovers@ai.mit.edu
  158. Subj:   Announcement of new Kermit-12 utilities
  159.  
  160.     Currently available at watsun.cc.columbia.edu via ftp in
  161. /pub/ftp/kermit/d/k12*.* are two new files: k12enc.pal and k12dec.pal.
  162. The new files have internal dates of 1-Mar-92.
  163.  
  164.     These are the newly updated ENCODE and DECODE programs for moving
  165. around OS/8 binary files.  There is a new feature added to both, the
  166. ability to deal with "raw" image data.  Consider the following usage:
  167.  
  168. .R ENCODE
  169. *BIGGY.EN<RXA1:/I=756
  170.  
  171. When the input specification is a device only AND the /I switch is
  172. given AND a non-zero equals parameter is given, then the ENCODEd file
  173. is created containing the entire logical device for the length
  174. specified in the equals parameter.  In the example, the length of an
  175. RX01 in OS/8 terms is used.
  176.  
  177.     Note that the device need not be an OS/8 "legal" structure, and
  178. there is no individual input file significence either.  The user must
  179. set the length to whatever is appropriate.  Too large a number could
  180. result in program abort due to handler-reported input error.  The
  181. minimum length is 1; a zero-value is the same as leaving out the
  182. parameter.  (This is a restriction of OS/8 itself.)  Input data
  183. always starts at OS/8 logical record 0000.
  184.  
  185.     Note that the device must be definable within the scope of the
  186. selected OS/8 handler itself, since it is used for all input I/O
  187. using "raw" sequential calls.
  188.  
  189.     For example, an OS/8 bootable RX01 standard-format diskette would
  190. be acceptable for encoding here, while a WPS document disk would not
  191. be.  The reason is that the handler does not access track zero (not a
  192. WPS issue) and also does all reads in 12-bit mode, while WPS
  193. documents are written in 8-bit mode, portions of which are lost when
  194. using a 12-bit mode handler.
  195.  
  196.     By using another (user-written) handler that supplies 8-bit
  197. transfers, the WPS document disk CAN be successfully transferred to
  198. ENCODE format intact.  (Note: there are no current 8-bit mode
  199. handlers for RX02 and RX50, just RX01; this is a separate problem
  200. being addressed elsewhere.)
  201.  
  202.     Output DECODing is accomplished in a symmetrical manner:
  203.  
  204. .R DECODE
  205. *RXA1:<BIGGY.EN/I=756
  206.  
  207. The equals parameter need not be exact, but must be at least as large
  208. as the parameter used when encoding.  A smaller value can be used to
  209. limit the transfer deliberately where appropriate.  For example,
  210. using =7 will only transfer the first seven records of the encoded
  211. file onto the target device.  If the encoded file contains a valid
  212. OS/8 device in complete image form, this amount will suffice to
  213. transfer only the directory to the target device.  This effectively
  214. aborts the transfer, so the user can look at the directory with DIR,
  215. etc., to determine suitability of the larger transfer, etc.
  216.  
  217. Warning:
  218.  
  219.     This usage writes over the output device starting at logical
  220. record 0000.  The (possibly present) previous OS/8 structure will be
  221. destroyed.  This is the intended function of this usage as the new
  222. data is meant to be moved to the beginning of an empty device.
  223.  
  224.     Overall program operation for all other operations remains
  225. unchanged.  As before, program documentation is contained in the
  226. source files.  Except for the new image transfer feature, the
  227. programs are totally compatible with their previous respective
  228. versions.  (Note, the latest and previous versions are NOT compatible
  229. with older versions!)
  230.  
  231.     There are no plans to upgrade the .BOO format encode and decode
  232. programs, since the .BOO format has no checksum protection.  This is
  233. deemed a necessary feature in a complete device image transfer, due
  234. to the likelihood of a long file, etc.  Since the maximum length of
  235. an OS/8 file is limited to 4088 records, the raw input will of
  236. necessity be limited to somewhat less than this size of records,
  237. depending on the efficiency of the run-length compression inherent in
  238. the data encoding.
  239.  
  240. cjl
  241.  
  242. ------------------------------
  243. Date:   10/18/91 20:00 EDT
  244. From:   Charles Lasner (lasner@watsun.cc.columbia.edu)
  245. To:     pdp8-lovers@ai.mit.edu
  246. Subj:   Announcement of additional KERMIT-12 utilities.
  247.  
  248.     While no changes have been made to the body of KERMIT-12 itself,
  249. several things have been changed/added.
  250.  
  251.     At the request of the KERMIT distribution service (KERMSRV)
  252. certain files have been slightly modified so they are acceptable to
  253. that bitnet, etc. facility.  (Seems to be a problem with LRECL>80.)
  254. All files are now 80 or less.  Except for the .DOC file, all it took
  255. was a little "cosmetic surgery" on a few lines.  FTP'd copies are
  256. mostly unaffected.  Most of the problems have to do with
  257. interpretation of the inter-page FF character being treated as the
  258. first character of the "record" in this non-stream-oriented system.
  259.  
  260.     At this time there is no actual doc file, as the file K12MIT.DOC
  261. is merely a truncation of the listing of K12MIT.PAL as passed through
  262. PAL8 and CREF.  Anyone with a system big enough to support a 200K+
  263. long source file can create this file themselves.  In addition, due
  264. to certain quirks within PAL8 and CREF "beating" against unix line
  265. conventions, the file K12MIT.DOC at watsun.cc.columbia.edu was
  266. slightly different from the precise output of the assembly process,
  267. but again, only a cosmetic change.
  268.  
  269.     Since this file greatly exceeded the KERMSRV restriction, it has
  270. been withdrawn in favor of the source fragment equivalent to it taken
  271. directly from K12MIT.PAL.  This source fragment is short enough that
  272. even an RX01-based OS/8 system can create the listing file from it
  273. thus recreating the original K12MIT.DOC locally.  All this will
  274. disappear in the future when a "proper" doc file appears.  In the
  275. meantime, K12MIT.DOC in whatever form it is available contains
  276. hardware hints and kinks, assembly options, and other info useful to
  277. users and anyone interested in the "innards" of the program, as well
  278. as an edit history of how K12MIT got to be where it is now starting
  279. from its "grandfather" K08MIT.  It ends at the first line of the code
  280. in K12MIT.PAL, but includes all of the special purpose definitions
  281. particular to the various devices supported, such as DECmate I,
  282. DECmate II, etc.  Any changes to customize KERMIT-12 are still
  283. accomplished using the separate patch file K12PCH.PAL which is
  284. unchanged.
  285.  
  286.     New files cover two areas: 1) direct loading without KERMIT-12,
  287. and 2) .BOO format support.
  288.  
  289. 1)  Many users have the hardware for running KERMIT-12, but don't
  290. already have it or another suitable program to acquire it yet, a real
  291. "catch-22" situation.  Towards that end, a set of utilities has been
  292. provided to directly load KERMIT-12 without already having it.
  293.  
  294.     Most PDP-8 sites do have access to some other machine.
  295. Hopefully, the serial connection to be used is fairly "clean" and
  296. error-free, or at least some of the time.  These programs depend on
  297. this fact.  This could either be a connection to a remote multi-user
  298. system or something like a null-modem connection to a nearby IBM-PC.
  299. The programs assume only a few things:
  300.  
  301.     a)  The connection is error free.
  302.  
  303.     b)  The other end doesn't absolutely require anything be sent to
  304. it to send data to the PDP-8 end.  (The -8 end will not send ^S/^Q or
  305. anything like that because this is unnecessary; all data goes only
  306. into PDP-8 memory directly.)
  307.  
  308.     c)  The other end will send the data at a time controlled from
  309. its end, or after at most one character sent from the PDP-8 end of
  310. the link.
  311.  
  312.     The first situation is illustrated by the example of a PC
  313. connected to the -8.  The -8 program is started, and it waits
  314. indefinitely after the -8 user presses any one key.  (The
  315. corresponding character is sent to the PC where it is ignored.)  The
  316. PC end is initiated with a command such as COPY K12FL0.IPL AUX: and
  317. the data goes to the -8.
  318.  
  319.     The second situation is illustrated by a remote system where a
  320. command such as TYPE K12FL0.IPL is available.  The delimiting CR is
  321. not typed at this time, and will be finished later by the loading
  322. program.  The initial connection up until the TYPE command is not
  323. covered by the loading program itself, so the user must supply a
  324. basic comm program, which is possible to accomplish in about 10 words
  325. or less if the rates are "favorable", or worst-case, a terminal can
  326. be used and the line switched over to the -8 at the appropriate time.
  327. In any case, CR or other appropriate character is hit on the -8 and
  328. the loading program echoes it down the line (and on the console) to
  329. initiate the data down-load.
  330.  
  331.     d)  The other end is assumed to send the file verbatim without
  332. insertion of <del> characters (octal 177) and upper-case/lower-case
  333. is preserved.
  334.  
  335.     If all of these assumptions are met, then the down-load
  336. accomplishs a partial acquisition of K12MIT.SV, the primary binary
  337. file of KERMIT-12.  The process must be repeated several times to
  338. acquire all portions.  If a local compare utility is available that
  339. can compare absolute binary files, perhaps the process can be totally
  340. repeated to assure reliable results by comparing runs.
  341.  
  342.     The method used is borrowed from the field-service use of a
  343. medium-speed serial port reader on the -8 for diagnostic read-in.
  344. This reader is *almost* compatible with the device 01 reader such as
  345. the PC8E.  The difference is that the *real* PC8E is fully
  346. asynchronous, whereas the portable reader just spews out the
  347. characters without any protocol.  The PC8E can't drop any characters
  348. in theory, although there are reports of misadjusted readers that
  349. drop characters at certain crucial data rates.  (The PC8E runs at
  350. full speed if possible, and failing this falls back to a much slower
  351. speed.  All operations depend on the use of the hardware handshakes
  352. of the IOTs etc., so nothing should be lost but throughput.
  353. Misadjusted readers may drop characters when switching over to the
  354. slower mode.)
  355.  
  356.     The reason the field reader is acceptable is that it is used only
  357. to load diagnostics directly into memory using the RIM and BIN
  358. loaders.  These minimal applications can't possibly fall behind the
  359. reader running at full speed.  This is the same principle used here
  360. to down-load KERMIT-12.
  361.  
  362.     The loading program is a 46 word long program suitable to be
  363. toggled into ODT and saved as a small core-image program.  The user
  364. starts the program and then (at the appropriate time) presses one key
  365. (usually CR if it matters) and the loader waits for remote input.  As
  366. the other end sends the data, it is directly loaded into memory.
  367. There is a leader/trailer convention, just like paper-tape binary, so
  368. at end-of-load the program exits to OS/8 at 07600.  At this time the
  369. user issues a SAVE command.  This completes the down-load of a single
  370. field of K12MIT.SV.
  371.  
  372.     At the current time, there are actually two fields of K12MIT.SV,
  373. namely 00000-07577 and 10000-17577, and there are two such loaders.
  374. There is no check for proper field, so the proper loader must be used
  375. with the proper data, else the fields will get cross-loaded and will
  376. certainly fail.
  377.  
  378.     Once the two fields are obtained as separate .SV files (named
  379. FIELD0.SV and FIELD1.SV) they can be combined using ABSLDR.SV with
  380. the /I switch (image mode) set.  The resultant can be saved as
  381. K12MIT.SV.  This, if all went well, is identical in every way to the
  382. distributed K12MIT.SV (which is only distributed in encoded form; see
  383. below).  Actual file differences will only exist in the extraneous
  384. portions of the file representing the header block past all useful
  385. information and the artifacts of loading which represent 07600-07777
  386. and 17600-17777 which are not used.  This is the normal case for any
  387. OS/8 system when any file is saved.  Merely saving an image twice
  388. will cause this to happen.  At this point, K12MIT.SV can be used as
  389. intended, namely to acquire, via KERMIT protocol, the entire release.
  390. It is recommended that the provisional copy of K12MIT.SV be abandoned
  391. as soon as the encoded copy is decoded since the encoding process
  392. provides some assurances of valid data (using checksumming, etc.).
  393.  
  394.     This process can be accomplished on any KL-style -8 interface
  395. including PT08, etc., or on the printer port of VT-78 and all
  396. DECmates.  When used on the DECmates, there may be some minor
  397. problems associated with the down-load which may have to be done as
  398. the first use of the printer port after power-on, or some other
  399. restriction.  The loader includes a suggested instruction for DECmate
  400. use if problematic (and raises the program length to 47 words).
  401. Also, due to observed bugs in the operating system (OS/278 only),
  402. there are restrictions on the use of ABSLDR.SV that cause certain
  403. command forms to fail while other seemingly equivalent forms succeed!
  404. This is documented in the latest K12MIT.BWR file in the distribution.
  405. The command form stated in the K12IPL.PAL file is the only known form
  406. that works correctly on these flawed systems.
  407.  
  408.     The format for down-load files is known as .IPL or Initial
  409. Program Load format.  It consists of a leader containing only
  410. lower-case letters (code 141-177 only) followed by "printable" data
  411. in the range 041 (!) through 140 (`).  Each of the characters
  412. represents six bits of data, to be read left to right as pairs, which
  413. load into PDP-8 12-bit memory.  The implied loading address is
  414. always to start at 0000 of the implied field.  The leader comment
  415. contains documentation of which field of data from K12MIT.SV it is.
  416. The trailer consists of one lower-case character followed by anything
  417. at all.  This is why it is crucial that DEL (177) not appear anywhere
  418. in the body of the file.
  419.  
  420.     Throughout the file, all codes 040 or less are ignored.  This
  421. allows for spaces in the lower-case leader for better readability,
  422. and for CR/LF throughout the entire file.  CR/LF is added every 32
  423. words (64 characters) to satisfy certain other systems' requirements.
  424. The trailer contains documentation on a suggested SAVE command for
  425. the particular data just obtained.
  426.  
  427. 2)  PDP-8 ENCODE format is the format of choice to obtain binary OS/8
  428. image files because of the validation techniques employed, etc.  This
  429. is the standard method of distributing K12MIT.SV as well as other
  430. "critical" files such as TECO macros and other image files.  In the
  431. MS-DOS world there exists another very popular format known as .BOO
  432. encoding.  It would be useful to support this format on the PDP-8 as
  433. well.
  434.  
  435.     .BOO format files are smaller because they use six-bit encoding
  436. instead of five-bit encoding, or at least in theory.  Both ENCODE and
  437. .BOO use repeat compression techniques, but ENCODE can compress
  438. 12-bit words of any value, while .BOO only compresses zeroes and that
  439. itself is based on a byte-order view of the data.  PDP-8 programs
  440. often include large regions of non-zero words such as 7402 (HLT)
  441. which would not compress when looked at as bytes.  Such files would
  442. show compression ratios quite different from the norm.
  443.  
  444.     In any case, .BOO format is useful on the PDP-8 because it allows
  445. inter-change with .BOO files created on other systems, such as PCs.
  446. This allows the exchange of unusually formatted files, such as TECO
  447. macros between PDP-8s and PCs.  (Both systems support a viable
  448. version of TECO.)
  449.  
  450.     The new KERMIT-12 utilities include a .BOO encoder and .BOO
  451. decoder, known as K12ENB.PAL (or ENBOO.PAL) and K12DEB.PAL (or
  452. DEBOO.PAL) respectively.  They use .BOO encoded files unpacked in the
  453. standard OS/8 "3 for 2" order to preserve the original byte contents
  454. when the files originate from other systems.  (Technically, .BOO
  455. format doesn't require this, but the obvious advantages dictate it.
  456. Anything encoded into .BOO format must merely have a 24-bit data
  457. structure encoded into four six-bit characters, so in theory any
  458. encoding of two adjacent PDP-8 12-bit words would be acceptable.  By
  459. additionally supplying the bits in OS/8 pack/unpack order guarantees
  460. the inter-system compatibility as well.)
  461.  
  462.     There is an inherent weakness in the original .BOO format which
  463. must be addressed.  .BOO format files always end on one of two data
  464. fields: either a repeat-zero compression field, or on a 24-bit field
  465. expressed as four characters.  Should the data in a 24-bit field
  466. consist of only two or even one bytes, there are one or two
  467. extraneous null bytes encoded into the field to complete it.
  468.  
  469.     Presumably the need to add the extra bytes is to allow validation
  470. of the format.  In any case, only the encoder knows just how many (0,
  471. 1, 2) bytes are extraneous.  We can presume that if the last byte is
  472. non-zero, it is significant.  If the last two are both zero, then the
  473. last or possibly both are extraneous with no way to tell.
  474.  
  475.     On PC systems, the general trend is to ignore these one or two
  476. extra bytes because so far there haven't been any complaints of
  477. failure.  I have personally discovered that a widely used PC .BOO
  478. encoding program (written in C) erroneously adds two null bytes as
  479. a short compression field beyond the data!  This is not a .BOO format
  480. issue, but rather a genuine program bug.  Apparently few PC users are
  481. concerned that encoding their files prevents transparent delivery to
  482. the other end.
  483.  
  484.     In the OS/8 world, the situation is quite different.  Each OS/8
  485. record is 256 words or 384 bytes.  If even a single byte is added,
  486. this creates an additional all-zeroes record.  Besides wasting space,
  487. it is conceivable that such a file could be dangerous to use under
  488. OS/8 depending on content.  (Certain files, such as .HN files are
  489. partially identified by their length.  File damage, such as
  490. lengthening a file from two to three records will confuse the SET
  491. utility, etc.)  Many files cannot be identified as having been
  492. artifically lengthened (and may be hard to shorten!), so this must be
  493. avoided.
  494.  
  495.     I have invented a fix for the problem: repeat compression fields
  496. are expressed as ~ followed by a count.  2 means two null bytes and
  497. is thus the smallest "useful" field to be found.  (It takes two
  498. characters to express what would take 2-2/3 characters in encoded
  499. format.  One null would only take 1-1/3 characters, not two, so this
  500. case is vestigial, but must be supported for the benefit of
  501. brain-dead encoders.) The value of 0 means a count of literally zero,
  502. thus ~0 is a "NOP" to a decoder.  I have successfully tested MS-DOS
  503. programs written in BASIC and C that decode .BOO files successfully
  504. even if ~0 is appended to the end with no ill effects.  (They
  505. correctly ignored the appended fields.)
  506.  
  507.     In my encoding scheme, ~0 at the end of a data field containing
  508. trailing zeroes means to "take back" a null byte. ~0~0 means to take
  509. back two null bytes.  Thus files encoded with ENBOO.PAL either end in
  510. a repeat-compression field as before, or in a data encoding field
  511. possibly followed by ~0 or ~0~0 if necessary.  The corresponding
  512. DEBOO.PAL correctly decodes such files perfectly.
  513.  
  514.     Should files encoded with ENBOO reach "foreign" systems, they
  515. will do what they always do, i.e., make files one or two bytes too
  516. long occasionally, with no other ill effects.  Files originating from
  517. such systems will certainly be lacking any trailing correction fields
  518. and will cause DEBOO to perform as foolishly as MSBPCT.  Extraneous
  519. null bytes will appear at the end of the file in OS/8 just as in
  520. MS-DOS in this case.  (Note that if the file length is not a multiple
  521. of 384 bytes, additional bytes are added by DEBOO as well, but this
  522. is not a design weakness of .BOO format.  It is caused by the clash
  523. of fixed record size and a variable size format.)
  524.  
  525.     Hopefully, files originating on OS/8 will be decoded on OS/8 as
  526. well, thus preserving file lengths.  Most "foreign" files will
  527. probably be ASCII, so the ^Z convention will allow removal of
  528. trailing null bytes at either end.  It is hoped that MS-DOS and other
  529. systems "upgrade" their .BOO format files to be compatible with the
  530. PDP-8 version.
  531.  
  532.     All KERMIT-12 files are available via the normal distribution
  533. "paths" of anonymous FTP and/or KERMSRV.  The user is directed to the
  534. file /ftp/pub/kermit/d/k12mit.dsk as a "roadmap" to the entire
  535. distribution.  Each .PAL file includes assembly instructions.  Most
  536. use non-default option switches and non-default loading and saving
  537. instructions, so each must be carefully read.  The development
  538. support files (TECO macro, .IPL generator, recent copies of PAL8,
  539. CREF, etc.) are included in the total collection.  Development is not
  540. possible on RX01 systems due to inadequate disk space, but RX02's are
  541. barely adequate with a lot of disk exchanges.  (Future versions may
  542. require larger disks for development.)
  543.  
  544. Charles Lasner (lasner@watsun.cc.columbia.edu)
  545.