home *** CD-ROM | disk | FTP | other *** search
/ ftp.barnyard.co.uk / 2015.02.ftp.barnyard.co.uk.tar / ftp.barnyard.co.uk / cpm / walnut-creek-CDROM / ENTERPRS / CPM / UTILS / A / ASMHELP.LZH / CHAP3.TXT < prev    next >
Text File  |  2000-06-30  |  6KB  |  127 lines
  1.                               CHAP03.TXT
  2.                          Version 1.03 01/29/85
  3.                         Bonnell Frost 74076,223
  4.                         Robert Flagg 72466,2332
  5.  
  6.                           Chapter 3  Overlays
  7.  
  8.          The  main part of many programs is generic code--it will
  9. operate  in very many CP/M,  usually Z80 and almost always  8080,
  10. environments. However, most computers are a little different from
  11. others,  and  this  particularly applies  to  the  communications
  12. software.  Ports,  initialization sequences,  and screen clearing
  13. sequences  all are individual things.  Consequently programs need
  14. some easy way to be customized. One practical solution is the use
  15. of overlays to contain the custom code.
  16.  
  17.          An  overlay  must  have a close  relationship  with  the
  18. program  being  customized.  In particular,  the  specific  entry
  19. points in the overlay must be known to the main program, and they
  20. must be rigidly adhered to if a sequence of different overlays is
  21. to  be  written and used.  In addition,  any utilities  that  the
  22. overlay uses in the main program must have known entry points  so
  23. that  they can be called easily.  Examples of overlays are to  be
  24. found  in  Irv  Hoff's MDM7XX programs and in  Ron  Fowler's  MEX
  25. program.  These  public  domain programs are available  for  many
  26. different   computers  thanks  to  the  customization  capability
  27. provided by overlays.
  28.  
  29.          In  almost all cases the program to be modified with  an
  30. overlay  must be written with that in mind.  In those  few  cases
  31. where  an overlay was not considered in the initial construction,
  32. the programmer generating the overlay must essentially  shoe-horn
  33. it into a location in the original code to accomplish his purpose
  34. without  doing  violence to the original  intention.  Writing  an
  35. overlay of this later type is not to be undertaken lightly.
  36.  
  37.         There are two different common methods for applying over-
  38. lays to programs.  The older,  more traditional,  method uses the
  39. utility  program DDT supplied with CP/M by Digital Research.  DDT
  40. can  be  formidable,  but its use in installing overlays  can  be
  41. handled as a canned procedure, even to the point of using a -.SUB
  42. file.  The  second  method,  simpler and  less  intimidating,  is
  43. through use of one of the versions of Ron Fowler's  MLOAD.  Let's
  44. first consider MLOAD.
  45.  
  46.          MLOAD  is  available as an .AQM file or as a  .COM  file
  47. from many boards.  While copyrighted,  it is in the public domain
  48. in  so far as non-commercial use is concerned.  The documentation
  49. here is derived from that supplied in the code by  Fowler.  MLOAD
  50. allows  one  to start with either a .COM file or a .HEX file  and
  51. apply the desired overlay as a .HEX file. The resulting .COM file
  52. can  be either named the same as the original or as a  completely
  53. new name, as you desire. The syntax of use is as follows:
  54. .PA
  55.         MLOAD [<outfile>=]<file1>[,<file2>...] [BIAS]
  56.                 (brackets denote optional items)
  57.  
  58.                 <outfile> is the optional output file name
  59.                 <filen> are input file(s)
  60.                 <BIAS> is a hex load offset. (If you don't know what
  61.                         this means, you don't need it.)
  62.  
  63.                 <file1> may be an optional non-HEX (i.e., .COM)
  64.                         file to be patched by subsequent .HEX files.
  65.                         A non-HEX extension must be given, can't
  66.                         be assumed.
  67.  
  68.          Some examples:
  69.  
  70.                 MLOAD MEX.COM,KPO-41
  71.                 This sequence applies the overlay KPO-41.HEX to MEX.COM
  72.                 and stores the result in MEX.COM.
  73.  
  74.                 MLOAD MDM7TEST=MDM720,MDM7US
  75.                 This command string loads the file MDM720.HEX,
  76.                 applies the overlay MDM7US.HEX and stores the result
  77.                 as MDM7TEST.COM.
  78.  
  79.          Also, ZCPR-style DU specs can be used with MLOAD21:
  80.  
  81.                                                       :PATCH1,A8:PATCH2
  82.                 This string, issued from B3, generates NEWFILE.COM
  83.                 in A4 from OLDFILE.HEX in A0, PATCH1.HEX in B6, and
  84.                 PATCH2.HEX in A8.
  85.  
  86.          This last shenanigan is likely to to needed rarely.
  87.  
  88.          Now let us consider the use of DDT.  Here the  operation
  89. is  done  interactively,  not  as a consequence of  entering  one
  90. command string.  Also,  bear in mind that the cue for DDT is a -.
  91. Files given to DDT must be complete with extension.  One  vanilla
  92. example:
  93.  
  94.          DDT MEXNEW.HEX
  95.          DDT VERS 2.2   <---returned by the command
  96.          NEXT PC        <---returned by the command
  97.          6500 0100      <---returned by the command
  98.          -iKPO-41.HEX   <---specify overlay file
  99.          -r             <---read it in
  100.          -g0            <---exit from DDT
  101.  
  102.          WARM BOOT      <---system response
  103.  
  104.          A>SAVE 65H  MYMEX.COM  <---create .COM file from memory image.
  105.                 --OR--
  106.          A>SAVE 101  MYHEX.COM
  107.  
  108.         A  f0-
  109.          A>SAVE 101  MYHEX.COM
  110.  
  111.         A  few  more things must be considered.  The "i"  command
  112. sets up the overlay file to be read, the "r" command reads it and
  113. applies  it to the code already in memory from the invocation  of
  114. DDT.  G0  starts an execution at location 0,  which results in  a
  115. WARM  BOOT.  SAVE simply reads 65H 256-byte blocks of memory  and
  116. saves it as a COM file.   The generic CP/M SAVE command does  not
  117. understand  a  HEX length,  so that the 65H must be converted  to
  118. decimal 101 for it. The 65H comes from the first two bytes of the
  119. length given by DDT. If ZCPR is being used, 65H is a lot simpler.
  120. SAVE is stupid;  it will save it as MYJUNK.JNK if that's what  is
  121. specified.  Oh, yes, a simple HEX to decimal algorithm: 16*(first
  122. byte)+second  byte,  where  the  bytes are expressed  in  decimal
  123. (i.e., A is 10,E is 14.).  In this particular instance, since the
  124. last two bytes of "LAST" are zero,  the SAVE count is one  higher
  125. than necessary, but this is not important unless the same program
  126. is modified repeatedly, growing by 256 bytes each time.
  127. sidered.  T