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 / CPM / NSTAR / GENEUSYS.DQC / GENEUSYS.DOC
Text File  |  2000-06-30  |  14KB  |  249 lines
  1. February 24, 1981                      R. L. Plouffe
  2.                               (703) 527-3215
  3.  
  4.                           GENEUSYS.DOC
  5.  
  6.                         a description of:    
  7.  
  8.                  GENEUSER.ASM  and  GENESYS.ASM
  9.  
  10.                          * * * * * * *
  11. 12/14/81  GENEUSER.ASM rev 3.0 is a major re-write which  extends 
  12. the  CCP  and  allows  N  additional  user-defined  commands.  As 
  13. distributed,  it contains CCP-included code for BYE, LOGIN, ORIG, 
  14. ANSWR,  and PASS.  It has three password levels (0, 1, & 2) which 
  15. permit certain commands at each level.   Transient commands  have 
  16. the same three levels by placing transients in user 13, 14, or 15 
  17. respectively on drive A. Files are universal in all user areas on 
  18. drive  A  only if they are in one of these three user  areas  and 
  19. depending on password level achieved.
  20.                          * * * * * * *
  21.  
  22. The purpose of the files on this disk is to create a user area in 
  23. cp/m  as distributed by Lifeboat associates for north star double 
  24. density controller oriented systems that is expanded by either  1 
  25. or 2 kb.   This is done by writing to and reading from the  first 
  26. four sectors of the north star disk. This is where the additional 
  27. user  code  is  made  to  reside.  The  key  to  the  process  is 
  28. GENESYS.COM  which initially loads at 100H but immediately  moves 
  29. itself to just above the 'sysgen' image (2D00H), thus leaving the 
  30. ram space from 100H to 08FFH available to write user code. When a 
  31. cpm.com  file is SAVEd after patching in user code with DDT,  the 
  32. second  area of user code is saved along with the rest  of  cp/m. 
  33. GENESYS  is  then  used to write this cp/m system to  the  system 
  34. tracks starting from the first sector of the first track and from 
  35. RAM  starting at 100H.  The code in the first block in  the  100H 
  36. page  must contain a special ORG at 05CH of that page and a DS  1 
  37. placed  there.  This  is to provide storage space for the  format 
  38. byte which the lifeboat bios checks there.   This special ORG  is 
  39. contained in GENEUSER.ASM in its INIT routine.
  40.  
  41. GENESYS patches into your system a completely new coldboot loader 
  42. that  loads  all 10 sectors of both system tracks except that  it 
  43. skips  sector  four of the first track since the boot  prom  will 
  44. have  already loaded that code.   The coldboot loader is made  to 
  45. run  at CCP-100H as before and it loads the rest of the  code  to 
  46. ram starting at CCP-900H. Thus, the cp/m system is in it's normal 
  47. location  with  additional code from CCP-900H to CCP-100H  (2kB).  
  48. The  scheme in GENEUSER.ASM is to run the user INIT routine  here 
  49. since  it is throw away code anyhow and will get clobbered  since 
  50. this  is  in the top of the TPA.   The INIT routine  in  GENEUSER 
  51. contains  a mover which moves the second user area code which  is 
  52. also  now in ram between CCP-100 and CCP-900H to just  above  the 
  53. running cp/m system.
  54.  
  55. A  feature of the new cold boot loader is that in the event of  a 
  56. bad  disk read,  the loader will permit a reboot only eight times 
  57. and then reset the controller and halt the computer if still  not 
  58. successful  instead of rebooting endlessly as the loader in  your 
  59. distribution  version  will do.   This is important if  you  have 
  60. implemented  auto  power up and power down using the  PMMI  modem 
  61. auxiliary interface and your computer is activated remotely.  Who 
  62. wants  the  possibility  of  endless  head  loading,   unloading, 
  63. stepping and disks whirring until you get home - yuk.
  64.  
  65. GENESYS  also  patches your cp/m system so that it is  boot  PROM 
  66. independent. This is done by having the coldboot loader patch all 
  67. of  the PROM dependent bytes in the BIOS regardless of where your 
  68. PROM is located.  The coldboot loader is made to point to a table 
  69. already in your cp/m system that contains the addresses of  these 
  70. bytes.  Someone  put  an error in each of these tables  for  each 
  71. version  that  GENESYS knows about so it simply patches  out  the 
  72. error prior to writing out a system.   The error is apparently an 
  73. introduced  bug  to  prevent  the system from  working  when  you 
  74. relocate  your disk controller PROM.   The coldboot  loader  then 
  75. uses  the  table to patch all of the prom dependent  bytes  using 
  76. knowledge  of  the  prom location passed to it by the  boot  prom 
  77. firmware itself.
  78.  
  79. GENESYS  and GENEUSER will work with Lifeboat's cp/m 1.45,  2.01, 
  80. 2.2, 2.21A & 2.22.  The tables,  prom info storage locations, and 
  81. exit  to  bios addresses are different from one  version  to  the 
  82. other,  however  GENESYS  knows about all of that and  tests  for 
  83. version number in the second byte of the serial number. That byte 
  84. is 0EH (14 decimal) for version 1.45, 20H for version 2.0 and 22H 
  85. for  version 2.2.  If anyone has modified the serial number  (who 
  86. would  do that?) and changed the second byte,  then GENESYS won't 
  87. work and will give a bad version message. Once the second byte is 
  88. tested,  then GENESYS patches the cold boot loader to contain the 
  89. proper addresses before writing out your system to either a  file 
  90. or  to  your  system tracks.  Oh yes,  I forgot to  mention  that 
  91. GENESYS  (unlike Sysgen) has an option which you will see in  the 
  92. prompts  to  make  and write a cpm.com file or to  write  to  the 
  93. system tracks on the selected destination drive.  When writing  a 
  94. cpm.com  file  with GENESYS,  writing a system from one  disk  to 
  95. another,  or  taking  a  cpm.com file from one disk  and  writing 
  96. either a system or a file to another drive,  GENESYS will  always 
  97. check  the  format byte of the destination drive and  patch  that 
  98. byte  into the image before writing to that disk.  So the  format 
  99. byte  which  the files on that drive were written for is  assured 
  100. not  to be changed.   This is especially important for  cp/m  2.2 
  101. which  can  read or write from or to any of the defined  lifeboat 
  102. formats.
  103.  
  104. Since  GENESYS initially loads at 100H (but not above  8FFH),  it 
  105. will  not permit you to skip the source drive prompt as  'Sysgen' 
  106. will in order to write out a system that had been brought in with 
  107. DDT.  This  is  because  GENESYS first loads at  100H  and  would 
  108. clobber  any code from 100H to 08FFH that DDT would have written. 
  109. So,  you must bring in the image with GENESYS from either a  file 
  110. or  system tracks and not with DDT.  You can bring in a  cp/m.com 
  111. file  on the command line with GENESYS,  but it must be 40  North 
  112. Star blocks in length because GENESYS tests such a file to see if 
  113. it is complete.   So,  when you save a cpm.com file that has been 
  114. patched  with  DDT  always  save it  as  SAVE  40  (Dr:)CPMxx.COM 
  115. (xx=sysize).  Even if the SAVE prompt as a result of making a new 
  116. system  with  MOVCPM  under  1.45 says to SAVE 36 do  a  SAVE  40 
  117. instead.
  118.  
  119. When  patching  in a revised user area with DDT use  the  overlay 
  120. offset  computed in the GENEUSER.PRN file but first fill 100H  to 
  121. 8FFH  and  2700H  to 28FFH to zero (2400H  to  28FFH  when  using 
  122. version  1.45).  All of the code will appear in the right  places 
  123. from 100H to 2900H.
  124.  
  125. **************************IMPORTANT******************************
  126. Start  out  fresh with a cpm.com file made from MOVCPM  with  the 
  127. prom  dependent  bytes  unchanged and at  the  standard  location 
  128. (0E800H).  Then  overlay the user code from GENEUSER  using  DDT. 
  129. Then SAVE this image as a cpm.com file. Then use GENESYS to write 
  130. to  the system tracks.  The prom dependent bytes will be  changed 
  131. only  in the running system and not in the cpm.com file  although 
  132. other  clean up to the cpm.com file will be done when making such 
  133. a  file  with  GENESYS.  If you have  already  changed  the  prom 
  134. dependent bytes in MOVCPM manually, then you must change the PROM 
  135. equate  in the coldboot loader of GENESYS.ASM as well as the disk 
  136. read  command (0EB40H) in the bios options area  of  GENEUSER.ASM 
  137. for  version 1.45 in spite of the admonitions in those files  not 
  138. to do so.  Then perform the four steps just covered above in this 
  139. paragraph.  Either  procedure will then give you a disk that will 
  140. boot  up and run on any North Star regardless of where it's  disk 
  141. controller  PROM  is located.  Procedure 1 is preferred  but  any 
  142. other procedure will invite DISASTER since the coldboot loader is 
  143. going  to add the difference between the actual prom hi byte  and 
  144. the  value  contained in the coldboot loader to all of  the  prom 
  145. dependent bytes in the bios.  So if you had already patched these 
  146. bytes  manually  and don't start fresh (procedure  1)  or  follow 
  147. procedure  2,  the  new  coldboot loader will add  an  additional 
  148. offset  to all of the prom dependent bytes and your  system  wont 
  149. run.  So,  a  word  to  the wise - be careful and make  sure  you 
  150. understand  this procedure.  Once you have started fresh  (either 
  151. procedure) as outlined above,  you can always make your CPMxx.COM 
  152. file  using  GENESYS prior to patching in a new or  revised  user 
  153. code  using GENEUSER and DDT provide that the image brought in is 
  154. one that originated from a fresh start.
  155.  
  156. If  you change the user code in GENEUSER,  keep the same skeletal 
  157. organization.  Key parts of the skeletal are the movers, the orgs 
  158. including the special org at INIT+5CH.  You may add code in front 
  159. of  USR1END and USR2END to the extent that you have space in  the 
  160. two areas available and have properly allocated space above  cp/m 
  161. by  sizing  your system appropriately.  Also any code in an  area 
  162. that  has  labels  followed by EQU  $+OFFSET  must  be  similarly 
  163. labelled and equated.  The GENEUSER file provides for USER1 to be 
  164. 256  bytes to be compatible with version 1.45 without the  buffer 
  165. being  moved (you can make USER1 an additional 1k bytes  resident 
  166. on  the system tracks with 1.45 by moving the buffer up by 1k  or 
  167. to any place else out of the way).  USER2 can be either 1 or 2 kB 
  168. and  you must make space above cp/m by appropriately sizing  your 
  169. system.  Actually USER2 in its running location will be less than 
  170. 2  kB  by the amount of code in the INIT routine since that  code 
  171. doesn't  get  moved but gets thrown away,  so if you make  a  2kB 
  172. USER2 area there will be some space at the top which you can  use 
  173. as a scratch area for other purposes.
  174.  
  175. GENESYS is written using only 8080 mnemonics.  GENEUSER uses Z-80 
  176. code  stored  as  DB's  so that it will  assemble  with  an  8080 
  177. assembler.  The Z-80 implementation saves considerable space  but 
  178. you  should easily be able to convert it if your computer is 8080 
  179. based. Just keep the same skeletal arrangement.
  180.  
  181. GENEUSER  contains  a  number  of goodies  such  as  full  IOBYTE 
  182. implementation,   PMMI  modem  routines,  Computime  T-102  clock 
  183. routine,  and  North Star parity memory error detection  and  ram 
  184. parity  error message.  Look through it carefully to check all of 
  185. the conditional assemblies, port assignments and equates for your 
  186. system including clear screen,  mode byte and selection of  drive 
  187. characteristics in the bios options area,  and configuration byte 
  188. also in the bios options area.  You don't need to know controller 
  189. PROM  location  for parity memory option since GENEUSER will  get 
  190. this as a passed parameter either from the bios in 2.0/2.2 or the 
  191. coldboot loader for 1.45.
  192.  
  193. Now,  what  the  heck is all of this good for.  Well  aside  from 
  194. GENESYS  cleaning  up  your  system  so  that  it  will  be  disk 
  195. controller PROM independent, work with any version in conjunction 
  196. with GENEUSER and provide for expansion of user space resident on 
  197. the  system  tracks,  the reason this project got started was  to 
  198. provide  for  substantial  amounts  of  space  for  communication 
  199. networking  and  file  transfer software to be  resident  at  the 
  200. user's  beck  and call and available remotely as well  upon  auto 
  201. start up and answer using the PMMI modem.  The next project is to 
  202. get that code in there.
  203.  
  204.                          SPECIAL NOTE
  205.  
  206. If you have version 2.21A by Lifeboat, there are a couple of bugs 
  207. which you should know about.   First,  the user area code on  the 
  208. distribution diskette has an IOBYTE implementation but contains a 
  209. serious  flaw.   The author apparently forgot to save and restore 
  210. registers  in the routine that maps logical to physical  devices. 
  211. If you wish to use that code,  it is recommended that you  change 
  212. the  mapping routine to the one contained in GENEUSER.ASM that is 
  213. on this disk as a companion to GENESYS.   Otherwise you will find 
  214. that the user code on the distibution diskette will not work with 
  215. software  such as BYE.COM and MODEM.COM by Ward  Christianson  as 
  216. well as MBASIC ver 4.4 although it will work with MBASIC 4.51. It 
  217. is  suspected that plenty of other software that is not expecting 
  218. registers  to  be  corrupted would not  work  either.  Of  course 
  219. GENEUSER will work with all of the above.   The second bug has to 
  220. do   with the MODE byte.   The bios on the distribution  diskette 
  221. has a stack imbalance in the routine that tests the MODE byte and 
  222. POPs  the  PSW  once too many times if the 40H  bit  (READ  AFTER 
  223. WRITE) is set high.   This is corrected in the FIX221A subroutine 
  224. of  GENESYS by setting the extra POP PSW byte  to  NOP.   Without 
  225. this  correction,  the  read-after-write function does  not  work 
  226. properly  and  FORMAT.COM as well as PIP.COM do not work.   So  a 
  227. system  that is 'gened' with GENESYS has this bug fixed  and  you 
  228. can  set  the read-after-write function in the MODE byte  without 
  229. fear. These bugs were fixed by Lifeboat in ver 2.22.
  230.  
  231.  
  232.  
  233.  
  234.  
  235.                    ****** C A U T I O N ******
  236.  
  237.           ONCE YOU USE GENESYS TO 'GEN' YOUR  SYSTEM,  DO 
  238.           NOT USE 'SYSGEN' ANYMORE SINCE IT WILL NOT READ 
  239.           OR  WRITE  THE FIRST FOUR SECTORS OF THE  FIRST 
  240.           TRACK.  RETIRE 'SYSGEN' TO THE ARCHIVES,  SINCE 
  241.           GENESYS  WILL  DO  THE SAME AND  MORE  EVEN  ON 
  242.           SYSTEMS THAT HAVE BEEN 'GENED' USING 'SYSGEN'.
  243.  
  244. Have  fun  and let me know how you make out,  but  no  complaints 
  245. please.
  246.  
  247.                     r.l.plouffe
  248.  
  249.