home *** CD-ROM | disk | FTP | other *** search
/ GEMini Atari / GEMini_Atari_CD-ROM_Walnut_Creek_December_1993.iso / files / telecomm / kmterm19 / km_term.bug < prev    next >
Encoding:
Text File  |  1993-04-20  |  3.5 KB  |  83 lines
  1. KM_TERM Known Bugs :-
  2.  
  3. =====================
  4.  
  5.  
  6.  
  7. 1. Medium RES fonts loaded by e.g. Harlekin or FONTSEL.ACC work 
  8. fine on their own but cause KM_TERM to crash when QuickST3 is 
  9. installed.
  10.  
  11. --> This appears to be a bug in QuickST3 concerning the GEMDOS 
  12. 'CCONWS' call. It doesn't occur with Turbo ST or QuickST 2.
  13.  
  14.  
  15.  
  16. If you wish to use an alternative screen font with KM_TERM in 
  17. medium RES with QuickST3 installed, use the custom font handling 
  18. incorporated in the QuickST customiser accessory or better still 
  19. use QUICKSTC.PRG (v2.1)
  20.  
  21.  
  22.  
  23. ----------------------------------------------------------------
  24.  
  25.  
  26.  
  27. 2. On exiting KM_TERM, the desktop retains the selected KM_TERM 
  28. palette.
  29.  
  30. --> Now fixed in v1.3
  31.  
  32.  
  33.  
  34. ----------------------------------------------------------------
  35.  
  36.  
  37.  
  38. 3. It has been said that KM_Term can refuse to run after DTerm has 
  39. been used and reports a bad channel error; apparently if you double 
  40. click on KM_Term several times it will eventually run.
  41.  
  42. --> I suspect that DTerm sets up some system variables that 
  43. conflict with the ST's standard VT52 emulation mode. I've noticed 
  44. the same error message if I freely mix Power BASIC's LOCATE & PRINT 
  45. commands with the GEMDOS calls cconws and cconout. As it's an 
  46. internal ST system problem I doubt if it can be fixed, but similar 
  47. problems don't appear to occur with other programs as I've 
  48. regularly run other programs from within KM_Term and vice-versa, 
  49. including some that are much more sophisticated than DTerm (e.g. 
  50. FzDz)
  51.  
  52.  
  53.  
  54. In this particular instance, however, it's difficult to attribute 
  55. blame to any individual program since both were being run from the 
  56. ETERNAL RAM disk (which could itself be a cause of a clash I 
  57. suppose)
  58.  
  59.  
  60.  
  61. ----------------------------------------------------------------
  62.  
  63.  
  64.  
  65. 4. A bug crept into versions 0.7 onwards that prevented the VT52 
  66. esc-Y positioning from working correctly - thanks to Mark Matts for 
  67. helping to discover this one.
  68.  
  69. --> Fixed in version 1.63 onwards (It appears that the lack of setup 
  70. required for KM_Term may have masked this one; KM_Term may have been 
  71. responding to ANSI codes correctly when I assumed it was handling 
  72. VT52!)
  73.  
  74. Actually this one really made me feel small; it seems that about 20 
  75. characters from a bit of good code somehow went missing (spot the 
  76. backspace key repeat!!) but unfortunately the code still made sense 
  77. to the compiler - ah well..
  78.  
  79.  
  80.  
  81. ----------------------------------------------------------------
  82.  
  83.  
  84.  
  85. 5. The standard rate Mercury call charging was reported as being way 
  86. out.
  87.  
  88. -->When I checked this I couldn't duplicate it, but on closer 
  89. inspection I realised that whereas my call cost rates were separated 
  90. by commas, the standard ones built in to the default configuration 
  91. were separated by spaces; this caused KM_Term to interpret the 
  92. standard rates as [standard] x 10^[economy] - whoops.
  93.  
  94. The simple way to fix this is to change the spaces in the 'T1>' to 
  95. 'T4>' lines to commas with a text editor. The defaults are fixed in 
  96. v1.7.
  97.  
  98.  
  99.  
  100. ----------------------------------------------------------------
  101.  
  102.  
  103.  
  104. 6. It has been reported that KM_Term doesn't allow the download and 
  105. upload paths to be on different drives to the main program. This 
  106. turned out to be a GEMDOS 'dsetpath' feature (bug!) that is fixed 
  107. with some hard disk driver software (This is why it was overlooked 
  108. unfortunately). I have overcome this problem in v1.8.
  109.  
  110.  
  111.  
  112. ----------------------------------------------------------------
  113.  
  114.  
  115.  
  116.  
  117.  
  118.  
  119.  
  120. No other reported bugs at 20 April 1992
  121.  
  122. =======================================
  123.  
  124.  
  125.  
  126.