home *** CD-ROM | disk | FTP | other *** search
/ ST-Computer Leser-CD 1999 January / STC_CD_01_1999.iso / base / pd_ph105 / read_me.txt < prev    next >
Text File  |  2000-01-08  |  15KB  |  337 lines

  1. This patch is supposed to bring the Pure Debugger to modern times. 
  2. The problem is, that (AFAIK) ASH is not allowed, for license reasons,
  3. to make an update by themselves. Therefore somebody else had to do it
  4. without the source code. Since I like using PD I did it.
  5.  
  6. Problems of PD I know of, theire conditions of occurrence, and theire 
  7. status (S = solved, N = not solved, U= understood but still unsolved):
  8.  
  9. NR.    SNU occurence         Explanation
  10. 1    U    Multitasking    Sometimes at leaving PD the left Mousebutton seams 
  11.                         pressed
  12.  
  13. 2    S    MagiC            PC can't start PD as singletask
  14.  
  15. 3    S    MagiC...        PD does not closes open files on 'Program reset' 
  16.                         -> on restart Fopen produces an error
  17.  
  18. 4    S    always            PD does not uses XBRA
  19.  
  20. 5    S    always            PD redirects vectors but does not test if a program, 
  21.                         jumping over these vectors is PD or anybody else -> 
  22.                         for example if a program, running parallel to PD 
  23.                         finishes  (Pterm) PD assumes, that this means, 
  24.                         that the program to debug has finished.
  25.  
  26. 6    U    Graphiccard        changing screen per Setscreen does not work
  27.  
  28. 7    S    always            On running the first program, PD prints an ESC H -> if 
  29.                         a console window (Gemini,...) is open, the Cursor goes
  30.                         to the upper left corner.
  31.  
  32. 8    S    multitasking    sometimes the wrong Menu is visible
  33.  
  34. 9    S    MINT            PD does not work at all, I was tolled
  35.  
  36. 10    S    2 monitors         this is not solving an error, but adding a new feature: 
  37.                         you can now run    PD on 2 monitors
  38.  
  39. 11    S    ?                   Sometimes the mouse cursor disappears
  40.  
  41. 12    S    multitasking    PD sometimes try to get memory at the top end, this routine sometimes
  42.                         fails under multitasking OS and always under MagiC. Normely this has
  43.                         no direct effect, since PD reserves mamory at a random position in this
  44.                         case.
  45.  
  46. 13    S    ?                For some time the one monitorversion, including the unpatched PD halted
  47.                         when it tried to change the screen by Setscreen. Since changing the method
  48.                         in the option menu did not helped an other patch become nessessery
  49.  
  50. 14    S    >Gemdos0.19        PD memorizes all Malloc actions to be able to free this memory in program
  51.                         reset. But it ignores Mxalloc
  52.  
  53. General
  54. *******
  55.  
  56. To add new routines, some addresses in PD have to be known. This addresses 
  57. are stored in PD_ADDR.DAT. On the first run Patch tries to find this adresses 
  58. and stores them for future use. But this is not foolproof:
  59. - The searched routines have changed (different PD version than mine)-> wrong
  60.     or no address found
  61. - Somewhere else something has changed, so that by chance it looks 
  62.     like the routine -> it seams to be found twice.
  63. If none or more then one occurrences are found, an error message is 
  64. issued. Since not all addresses are needed for every patch, you can 
  65. still try. If a needed adress is unknown the patch will stop.
  66. For easier control, there will be a textversion of pd_addr.dat written:
  67. pd_addr.txt
  68.  
  69. How does it works
  70. *****************
  71.  
  72. a) Run PATCH.PRG and answer the following questions:
  73.     a) One or two-monitor-version?: what ever you want. see 10)
  74.     b) May Setscreen be used? (will only be asked if patching a 1-monitor PD.
  75.         Ja=Yes; Nein=No
  76.         First try using Setscreen. Only if this produces a crash then make an
  77.         other patch and answer with no (Nein) see 13)
  78.     c)    When putting out ESC H ?: s. 7)
  79.         'nie'=never;1. Run; 'jedes Run'=every run
  80. b) if you wish to run the new PDs out of PC: copy the PD.PRG into the 
  81.     PC-directory. Therefore you have to rename the original PD.PRG
  82. c) test it
  83.  
  84. If you want to change something in the patch yourself please set the
  85. options in PC as follow:
  86. Compiler: -C, -P
  87. Assembler: -S
  88. Linker -G, -L, -F, Stacksize 100000
  89. usualy I also have -Y set in all 3 categories, but this is not mendatory.
  90. Now I also set this options in the PRJ-File, so setting them explicitly in 
  91. PC is probably not nececerry anymore.
  92. If for whatever reasens you are using an other Compiler but PC, don't expect
  93. to have no problems.
  94.  
  95. The different problems and their solutions
  96. ******************************************
  97.  
  98. 1) left mouse-button pressed
  99. ----------------------------
  100. Since menus, windows and the like are not drawn by AES in PD, but 
  101. are drawn directly by VDI on the screen, they are kind of invisible
  102. to mouse clicks. The only reason there are not more problems is 
  103. because PD runs in supervisor mode, but at the end of the programm
  104. problems occure. I tried solving this problem using 
  105. wind_update(BEG_MOUSCTRL) but received some strange effects.
  106.  
  107. 2) Running PD as single task (MagiC)
  108. ------------------------------------
  109. To be able to run PD out of PC in single task I wrote a starter (START_PD). 
  110. It starts PD by sending a message (AV-Protocol) to the shell. If this shell 
  111. understands AV it should find out, if PD has to be run in single task and if
  112. so start it in single task. There has been a problem with the desktop EASE,
  113. it did not gave PD the comandline. If you press the ALTERNATE button while
  114. starting START_PD it will ask some questions: 
  115. singeltask or multitask
  116. 1 or 2 monitors (PD_1.PRG or PD_2.PRG)
  117.  
  118. To make it clear, telling the starter to start PD as singeltask only works, if
  119. the AV-Server does it.
  120.  
  121. 3) open files
  122. -------------
  123. If at the end of the program (the one to be debugged) or on a break 
  124. there are still files open, the will still be open on a new run. Some
  125. OS like MagiC realise, that this file is tried to be opened for a 
  126. second time and exit an error. My solution is to log the calls of 
  127. Fcreate, Fopen and Fdelete. On 'program reset' these files are closed
  128. automaticly. Until now only handles between 6 and 63 are observed. If
  129. this should not be enough, change p_flags in PDX, and all routines
  130. using it. But the worst case possible is that PD reacts for files with
  131. handle >63 as it used to with any handle.
  132.  
  133. 4) XBRA
  134. -------
  135.  
  136. I introduced a XBRA structure for all routines changed by Setexc. 
  137. The ID is 'PDeb' for PD_1 and 'PDEB' for PD_2. 
  138. The XBRA-Impementation is complet now, meening, that also deinstalling
  139. is done by XBRA. But since PD is to be used with unfinished software,
  140. this is not always possible. So if the deinstalling routine does
  141. not find it's own ID, it will reset the vector to the original state.
  142. The reasen for using 2 ID's is, to be able to debug PD_1 with PD_2.
  143.  
  144. 5) identification of caller
  145. ---------------------------
  146.  
  147. PD does not test who is jumping over changed vectors. In single task 
  148. this is fine, but not in multitasking. One very 'nice' error occurs, 
  149. when you end a program running parallel to PD. PD exits the message 
  150. 'program terminated' and exits the run modus. But the program which 
  151. was debugged is still runnig, even after finishing PD! Don't ask me 
  152. what this can couse for problems (who ownes the memmory,...). Before
  153. finding out I always pressed reset. Now PD saves the adress of it
  154. Basepage at the beginning. Everytime a changed vector (XBRA) is used,
  155. it is tested if it's PD or not. Either the original routine is used or
  156. the PD one. This patch needs 4) and is needed for 3).
  157. For every rule there is an exeption. PD uses the hardcopy Interrupt as a break.
  158. (<ALT><HELP>) If this would be only active while PD is executetd, this would
  159. mean that you have to press <ALT><HELP> for some time. Since this routine only
  160. sets a flag, there is no problem of letting it being active even if a other
  161. programm is executed. This flag is tested during the vertical Blanc routine.
  162. Meaning, that the <ALT><HELP> is memorized at all time, but that PD only reacts
  163. if there is a vb during the time PD is executed. So if PD does not react try
  164. pressing a button, moving a Window of the programm debugged,...
  165.  
  166. 6) Setscreen
  167. ------------
  168.  
  169. PD reserves ST-RAM for a 2nd and 3rd screen, then it trys out if Setscreen 
  170. is working. Setscreen would work on some graphic-cards (NOVA,...) if their
  171. RAM and not ST-RAM would be used. So i tried to fake the malloc, but
  172. without success. The problem seems to be, that NOVA-RAM starts at
  173. 0xFEC00000 which is negative... . As a partial solution TT-Ram is used
  174. in case a graphic card is reccognized. By now only NOVA cards are
  175. recognized by:
  176.     if (get_cookie('IMNE',(long *)&icb))
  177.         X_pd.p_bs_m=3;
  178. for other graphic cards, the if-condition can either be changed to recognize
  179. other cards by adding '||...' or if the card is always used by deleting the 
  180. if totaly. X_pd.p_bs_m includes the Mxalloc modus. It is usualy 0, but will 
  181. be changed here to 3. This patch is only included in the one-monitor-patch.
  182.  
  183. 7) ESC H
  184. --------
  185.  
  186. On the first RUN PD prints ESC H, if a console window(Gemini,...) 
  187. is open, the cursor goes to the upper left corner. If this is
  188. wanted or not can be chosen by everybody self. I introduced 3
  189. possibilities:
  190. a) never printing ESC H
  191. b) only at the first RUN (as in the original)
  192. c) at every RUN
  193.  
  194. 8) Menu title
  195. -------------
  196.  
  197. In multitasking environments sometimes the wrong Menu is visible, 
  198. even if the right one is active. I did not found all circumstances
  199. under which it occurs. Therefor I only added an automatic redraw of
  200. the menu shortly after the start of the program, and for all other
  201. cases I added an manual possibility. Just click in the menu line
  202. (y<18) and the menu is redrawn. Of course this should be done in
  203. the right unused part of the menu. This is only included in the 
  204. one-monitor-solution, since this problem does not exist with 2 monitors.
  205.  
  206. 9) MINT
  207. -------
  208.  
  209. I don't know. I never installed MINT, I am not actually interested 
  210. in it. But Thomas Künneth and Chris Felsch wrote a starter which
  211. makes it possible to run PD under MiNT. I included this starter in my own
  212. ( see 2) ) and so it should be possible to use PD under MiNT now. 
  213.  
  214. 10) two monitors
  215. ----------------
  216.  
  217. This was the reason I started writing this patch in the first place. 
  218. With this version it is possible to use 2 monitors, similar to the 
  219. very good program, SYSMON. It is quite difficult to redirect AES-output,
  220. even more to a different resolution. But luckily this is not necessary,
  221. since PD only uses VDI-calls. Therefore it is only necessary to open 
  222. a OFF-Screen Bitmap and return PD that handle instead to the one
  223. expected of v_opnvwk. Besides the mouse curser has to be drawn by PD
  224. it selve. But all this problems are solved under some conditions:
  225. - VDI which supports OFF-screen bitmaps, either per v_opnvwk2 (NOVA-VDI) 
  226.     or by v_opnbm (NVDI, NOVA and others if the EdDI-cookie is present 
  227.     with version >=1.1)
  228. -ATARI-compatible monitor and second monitor by graphic card is present.
  229.  
  230. Problems could occur, if a second program, uses two monitors too, 
  231. but the only othe program doing so I know off, SYSMON works together with
  232. my one just fine.
  233.  
  234. There had been Problems with the programm BLACKSCR.PRG, which sets all colors
  235. of the 2nd monitor to black. This has only an effect in the monochrome mode
  236. on TTs. Thatfore if it is a TT I now set the colors to black/white.
  237.  
  238. Now I use a PC with MagiC PC. Since there I only have one monitor, I can
  239. actualy not use this feature myselv anymore
  240.  
  241. 11) disappearing mouse cursor
  242. -----------------------------
  243.  
  244. As I never observed this error by my self, or at least don't remember 
  245. observing it, which probably is mainly caused by the fact, that I 
  246. almost always use PD with 2 monitors, I only introduced a symptomatic
  247. solution. If the cursor disappears, just press the right mouse button
  248. and it should reappear. This is until now untested, but I am optimistic.
  249. If somebody manages to produce a reproducible state in which this error 
  250. occurs, then please let me know, and I may find a better solution.
  251.  
  252. 12) Malloc for high memory
  253. --------------------------
  254.  
  255. While trying to further improve my XBRA implementation (s. 4)) I analysed
  256. a routine and realized, that it had 2 errors. PD sometimes try to get 
  257. memory at the top end. That fore it first reserves all memory (in a loop
  258. containing Malloc(-1)) this fails if a other programm reserves memory in the
  259. meantime. This could be solved by changing the break - condition. Then PD
  260. looks for the highest so reserved block and trys to split it so, that tho top
  261. part gets the needed size. This does not funktions under MagiC, since there 32
  262. extra Bytes are reserved with any Malloc. For examble if the Block has 3000 Byte
  263. and PD needs 1000, PD shrinks (Mshrink) the Block to 2000 and trys to reserve 1000
  264. But under MagiC there are only 1968 Bytes left. To be on the safe side I now always
  265. shrink to 64 Bytes less then required under TOS -> I spoil 64 Bytes under TOS, 32 
  266. under MagiC. But maybe some other OS needs more. Of course I could calculate the
  267. exact length needed, but to save a few byte this is not sensible, certanly not if 
  268. the produced code would be longer than the saved memory
  269.  
  270. 13) Setscreen for 1 monitor
  271. ---------------------------
  272. This patch is optional and should only be used if PD otherwise does not run.
  273. I just exchanged the original Setscreen by an empty function:
  274. {}
  275. this works because PD checks after using Setscreen if it was sucsessful, and if not 
  276. uses an other way of changing the screen
  277.  
  278. 14 Mxalloc
  279. ----------
  280.  
  281. Since I already introduced my own Fopen, Fcreate and Fclose I decided to include a 
  282. complete Version of the Gemdos Dispatcher into the Patch. This also includes Mxalloc,
  283. where as with Malloc in the original PD all memoryallocation is memorized
  284.  
  285. 15) other changes
  286. -----------------
  287.  
  288. as said in 9) I will try to solve other problems with PD anybody tells 
  289. me off. It has a good reason, that I include the source code. So anybody 
  290. can include patches by himself, this is needed either when I am not
  291. reachable or if it's a problem I don't have on my configuration. But I
  292. recommend, that every change/addition is brought to my attention. I
  293. then will include it in a new public version. This definitely includes
  294. the case, that GET_ADDR does not finds an address by itself but you
  295. find it by yourself. 
  296.  
  297.  
  298. Fairware
  299. --------
  300.  
  301. This program is Fairware, it may be copied freely, but if somebody 
  302. needs to get rid of some mo- 
  303. ney...
  304.  
  305. Thanks to
  306. ---------
  307.  
  308. Bernhard Held volunteered as ₧-tester.
  309.  
  310. Thomas Künneth and Chris Felsch for their MiNT-starter
  311.  
  312. Wilfried Behne for his help in searching an error (in my patch)
  313. in connection with NVDI.
  314.  
  315. !!!!!!!!!!!!!!!
  316. !  Attention  !
  317. !!!!!!!!!!!!!!!
  318.  
  319. On no circumstance PD, either the original or a patched version may 
  320. be exchanged without the prior approval of ASH. This program may only
  321. be used to patch officially bought versions of the Pure Debugger. This
  322. is especially true, since some routines (xbra_exc and xbra_Gd_trm) 
  323. included in the source code are variations of the original PD code.
  324. These are specially marked.
  325. Exeption, I will give a patched version to ASH. Probably they will put
  326. it in their BOX, so that it is accessible to registered users. But since
  327. there are some options on patching PD, this is only 2nd best to patching it
  328. by yourself.
  329.  
  330. Author
  331. ------
  332.  
  333. Dimitri Junker
  334. E-Mail:                     Dimitri_Junker@AC3.maus.de
  335. or for long mails (>16k):    Junker@popmail.oche.de        
  336.  
  337.