home *** CD-ROM | disk | FTP | other *** search
/ CP/M / CPM_CDROM.iso / cpm / utils / dskutl / zap35.ark / ZAP35.DOC < prev    next >
Encoding:
Text File  |  1986-09-19  |  8.6 KB  |  171 lines
  1.         SUPERZAP MOD 3.5  DOCUMENTATION
  2.         from John T. Coburn  15 Sept 1986
  3.  
  4. V3.5  is  a bug fix for the SuperZap program.  The bugs only appeared when
  5. an ANSI style cursor addressing was used.  The cursor positioning routines
  6. have been fixed to work properly.  All  enclosed  documentation  is  still
  7. valid.   The default (in source) is now set to be an ANSI terminal and the
  8. wordprocessing end  of  line  features  are  disabled  by  having  0dH  in
  9. locations  SOFT1,  SOFT2,   HARD1  and  HARD2.  They can be changed by Z8E
  10. using the .LST file (ZAP35.LST).   I have also reset  the  cursor  control
  11. keys  to  the  default case (WordStar) and removed some confusing comments
  12. that indicated what the last person would  prefer but not what was  coded.
  13. The source file is ZAP35.Z80 and the symbol table file is ZAP35.LST.
  14.  
  15. Beware-  Several  of  the  routines  in this program do not save registers
  16. properly  even  though  the  program  uses  some  structured   programming
  17. techniques.
  18.  
  19. ==========================================================================
  20.  
  21.  
  22.         SUPERZAP MOD 3.4  DOCUMENTATION
  23.         from Peter G. Martin  24 July 1986
  24.  
  25. (UPDATED 24 July 1986 -- 3.4b version)
  26.  
  27. This  version adapts version 3.3 as updated by John Hastwell-Batten, SYSOP
  28. for  Tesseract  RCPM,  and  adds  some  additional  functions  on   John's
  29. 'wish-list' as well as some I had on my own wish-list.
  30.  
  31. In  particular,  it  adds  the ability in Edit mode to search for either a
  32. given ASCII string or a sequence of hex entered on screen.  The search can
  33. be continued repeatedly until end of file is found,  abandoned  after  any
  34. given  find,  and  after  any  search,  there  is an option to either stay
  35. positioned over the relevant sector or to return to the top of the file.
  36.  
  37. Ascii  searches  are  exact,  accepting  upper or lower case patterns (ie,
  38. there are no upper  case  matches  found  for  lower-case  characters  and
  39. vice-versa).
  40.  
  41. A  second  additional option permits 80 column 'typing' of files (at least
  42. on my machine), but also adds options to go to any given Sector,  Page  or
  43. Line of text files.  As this implies, the program has been coded to keep a
  44. check  on  lines,  given  that some assumptions are made (see below) about
  45. what a line end actually is.
  46.  
  47. I wanted this option because generally I can look quickly at the beginning
  48. of  text  files thru various other commands or programs (eg 'TYPE'), but I
  49. really wanted to be able to go straight to  the  area  I  wanted,  and  to
  50. browse backwards and forwards through files.
  51.  
  52. In  particular, if I wanted to do some smartish editing, I preferred to be
  53. able to 'view' a file, detect the sector number of the relevant data  that
  54. way,  and  then  be  able  to slip back into Edit mode, go directly to the
  55. sector concerned, and use the Change option where possible.
  56.  
  57. The  (excessive ?)  options added permit this with the choice of selecting
  58. a (screen) page number, a line number or a file sector number.
  59.  
  60. The  price  paid  for  the  flexibility  is  that  when the Type option is
  61. selected for a file, the program spends some time reading completely  thru
  62. the  file  to queue data it then can use to locate any desired position in
  63. the file.
  64.  
  65. An  alternative  way  to organise this bit was to load this data only when
  66. one of the GOTO options (sector,page,line no.)  was selected.  It  remains
  67. an  alternative  if  someone  wants to do it that way, and change the code
  68. around for that purpose.
  69.  
  70. The  code  has  grown considerably in volume.  Unquestionably, it could be
  71. trimmed.  I did a bit of minor trimming and some re-labelling when in  one
  72. or  two  places when I got sick of unpicking the trail of various relative
  73. jumps and non-sequentially numbered labels.
  74.  
  75. The  original  is  in  a  strictly-structured mode which I personally find
  76. excessive at times.  I have TRIED (oh God how I tried!)   to  keep  within
  77. the  spirit  of  this style of coding.  I suspect I didn't always maintain
  78. the faith...  but then,  I'm  not  a  zealous  believer...   (neither,  it
  79. appears,  is the old JHB, who can be found to have used some 'ret z's in a
  80. few places, (HORROR,HORROR!)
  81.  
  82. The  word-processor  'soft  newline' code assumes that so-called 'document
  83. mode' files will SOMETIMES use a SINGLE byte in place of a CR/LF pair, and
  84. SOMETIMES TWO BYTES, other than the  ASCII  standard  CR/LF,  0dh,0ah.   I
  85. re-checked  recently  to  find  that the left-handers control-key delight,
  86. Wordstar, uses 8Dh,0AH in  'document' files, as well as  the  single  0DH,
  87. sometimes....  or something...
  88.  
  89. Four  bytes,  imaginately called HARD1,HARD2,SOFT2 and SOFT3 are set aside
  90. to  deal with variations of this  kind  in  the  word  processor  of  your
  91. choice.
  92.  
  93. THESE  BYTES  CAN  SAFELY  ALL  BE  SET  TO  A  'NEUTRAL' 0DH if you files
  94. generally just have conventional 0D/0A combinations.
  95.  
  96. They   are  set  DIFFERENTLY  in  the  files  at  present,  to  allow  for
  97. alternatives for 'hard' and 'soft' key combinations....  by which is meant
  98. that IF your files, like Wordstar, for example, use a  2-byte  combination
  99. ending  in  0ah,  setting  EITHER  HARD1  or  HARD2  to  the  value of the
  100. 'different' lead-in (CR) byte -- in this case,  8DH,  will  permit  proper
  101. 'typing'  of  your  files, using the 'hard'  variations.  (leaving both at
  102. 0dh still gives you something readable).
  103.  
  104. SIMILARLY,  if,  as  is  the  case,  for  example,  with  SPELLBINDER,  my
  105. word-processor of choice, your 'document' files use a single  byte  (other
  106. than 0DH) in place of the CR/LF combo, you can set one or both of the SOFT
  107. bytes  to  those  values ...ie, in SPELLBINDER's case, to 0EH (most common
  108. soft line end) and 0CH (line end after a hyphen).
  109.  
  110. This is what I mean here by 'soft' -- a line end cue which consists of ONE
  111. byte only....  while the 'hard' cases use two bytes....  ending in 0ah, we
  112. hope!
  113.  
  114. All  four  bytes  -  2 hard, 2 soft, may be patched along with the various
  115. screen- control codes (see ZAP.33) and accessed at  018EH,018FH,0190H  and
  116. 0191H for SOFT1,SOFT2, HARD1 and HARD2 respectively.  If in doubt, SET ALL
  117. 4 TO 0DH and see how you go.
  118.  
  119. (You  can  even  use  SUPERZAP  to  patch  itself  quickly  to try various
  120. effects...  just try to remember to change it back if you create strife..)
  121.  
  122. Incidentally,  0DH  is already allowed for, 'hard - wired ' into the code,
  123. as a line end marker used by Wordstar and Spellbinder alike, and processed
  124. before these bytes are checked, so that the DEFAULT settings, set to  0dh,
  125. have  no real effect.  Other settings may have funny effects, particularly
  126. with non-ASCII files, so it's probably better to play safe.
  127.  
  128. There  are  one  or two minor unpleasantnesses about some of the new code,
  129. perhaps, and probably still the odd bug or two.  But it seems to work  for
  130. me  for  the  present.   (..  he said, having had to fix about 4 more bugs
  131. since that line was written....)
  132.  
  133. I  have  included  a  SYM  file  which is compatible with the good old z8e
  134. debugger (de best!).  
  135.  
  136. The  .C0M  file  included  has  screen options for Apple ][ cp/m (much the
  137. same,I  gather, as the Osborne) and some reconfiguration of  command  keys
  138. and menus away from the Wordstar-based original to something more suitable
  139. for right- handed people...  ?????
  140.  
  141. .... yes, well... ahem...
  142.  
  143. As  the  SYM  file  is  set  up for this version, you may care to look for
  144. $LEFT,$RIGHT,$UP,$DOWN and $END (currently set to ^H,^L,^K,^J and ^Z resp-
  145. ectively) if you want to go back to the Wordstar-ish originals.
  146.  
  147. The revised .MAC file is now supplied as modified, and with update notes.
  148.  
  149. As  at  24 July 1986, I think I have fixed two -- make that 4 -- bugs from
  150. the 11 July 1986 version,  one  of  which  was  MOST  unpleasant  on  some
  151. occasions,  involving  getting  lost  in  the  TPA  when a single byte was
  152. 'found' as the only byte searched for, as the last byte in the buffer.
  153.  
  154. A second bug involved an occasionally invalid assumption about whether the
  155. first  128 bytes of a file would contain enough line-ends to fill a screen
  156. 'page'.  We now assume it may, although I must say that the search routine
  157. is crudely sequential, and that a binary search through the ordered  queue
  158. would   probably  be  a  better  solution,  if  and when I or more likely,
  159. someone else, wants to get around to it...
  160.  
  161. One  or two further problems arose from clobbering of registers in some of
  162. the commonly-accessed routines such as RDFS.  Frankly, I  think  the  code
  163. could  do  with a bit more revision if more extensions are to be developed
  164. to ensure that registers are saved more consistently, particularly  before
  165. CPM calls.
  166.  
  167. ... but that's for another day...
  168.  
  169. P.G.M.    .... updated now to 24 JULY 1986
  170.  
  171.