home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / os / os2 / misc / 27850 < prev    next >
Encoding:
Internet Message Format  |  1992-08-20  |  4.7 KB
  1. Path: sparky!uunet!usc!sdd.hp.com!uakari.primate.wisc.edu!doug.cae.wisc.edu!umn.edu!orstnews!ucs.orst.edu!hilmera
  2. From: hilmera@ucs.orst.edu (Andrew Hilmer)
  3. Newsgroups: comp.os.os2.misc
  4. Subject: Trident 800x256 & downloading problems
  5. Message-ID: <1992Aug20.171356.18187@talon.ucs.orst.edu>
  6. Date: 20 Aug 92 17:13:56 GMT
  7. Sender: usenet@talon.ucs.orst.edu (Usenet News admin)
  8. Organization: University Computing Services - OSU
  9. Lines: 96
  10. Nntp-Posting-Host: ucs.orst.edu
  11.  
  12. Machine: generic asian clone, AMD 386/33, 64kSRAM, 8MbRAM
  13.          65 meg RLL drive, Supra 2400 internal modem
  14.          Trident 8900c w/1meg
  15.  
  16. Problems: Difficulty with background downloads.  
  17.           Non-fatal corruption of the WPS caused 
  18.           by the CMD.EXE shell, esp. in 132x43 mode.
  19.  
  20. 1.    I have not been able to download more than the simplest things
  21. in the background during downloads. I have tried various communication
  22. programs, including the bundled applet, Telix, and a few others.  I
  23. use PMqvt to download. I am able to play solitaire and other PM games
  24. while downloading, but if I start to switch to and from full screen
  25. sessions, start up emacs, or do some djpegging, I will peek back in on
  26. PMqvt and it will be recovering from errors, if it hasn't already
  27. acked. Needless to say, TE/2 (unregistered) is useless for
  28. downloading, since it dies with only the slightest prodding.
  29.  
  30. My IO card shouldn't have anything to do with it because my modem is
  31. on a card. Does drive access with RLL take up so much resource that it
  32. would do it? Ever since the install disasters, it doesn't seem to be
  33. THAT slow, compared to what others have said on the net. I am
  34. clueless.
  35.  
  36. 2.    Originally, I was running the plain 800x600x16 driver, and I
  37. don't remember having any problems. However, I am not sure that I
  38. discovered the 132x43 mode until after I installed the virtual desktop
  39. driver.
  40.  
  41. My initial ecstasy at finding this driver was short lived when I
  42. switched to the desktop and found the whole lower half of the
  43. 1024x1024 screen covered with a strange pattern of corruption. That is
  44. the LOWER half, which, I assume, points to some hanky panky in the
  45. lower(?) 512Kb on my video card. The corruption consists of many small
  46. vertical lines maybe 8-10 pixels high and about 2 wide. They are
  47. arranged very regularly about 30 pixels apart horizontally and about
  48. 60 pixels apart vertically (32x64?).
  49.  
  50. |---------------------|
  51. |                     |
  52. |                     |
  53. |                     |
  54. |                     |
  55. |'''''''''''''''''''''|  <-- Like so.
  56. |'''''''''''''''''''''|
  57. |'''''''''''''''''''''|
  58. |'''''''''''''''''''''|
  59. |---------------------|
  60.  
  61. The effect happens in this scenario. At the WPS. Start CMD.EXE. Switch
  62. back to the WPS. A row of these lines will appear at the very bottom.
  63. More on this row later.
  64.  
  65. If I run 132x43, this is what will happen. Start CMD.EXE. Switch text
  66. mode to 132x43. Alt-Esc (or Ctrl-Esc) back to the WPS. WPS has just
  67. the one line at the bottom. Switch back to the full-screen session.
  68. Switch back to WPS. Full corruption is now there.
  69.  
  70. Refresh takes care of any corruption that has not been laid on a
  71. window. To fix a window requires that it be completely redrawn.
  72.  
  73. The full screen session is not in any way corrupted.
  74.  
  75. If I start a Dos session, the WPS is immediately cured until the next
  76. time I switch to an OS/2 full screen session.
  77.  
  78. The lowest row of corruption lines are not spaced ~30 pixels apart,
  79. but are spaced much closer together. They also appear to be finer in
  80. width. Their vertical spacing away from the lines above them is not
  81. unique.  However, while they look as though the spacing of every fifth
  82. line is the same as those above, they are offset to the right a few
  83. pixels, instead of lining up into the columns made by the lines above
  84. them.
  85.  
  86. The coloration of this lowest row of lines is different as well. Every
  87. fifth line is just as randomly colored as all of the other lines. The
  88. three lines in between each of these, however, are uniformly black.
  89.  
  90. Also, when I was using the virtual desktop, I noticed that if I
  91. repeated the switching during the course of work, movement of the
  92. desktop produced more and more offset sets of corruption until I was
  93. annoyed enough to start a DOS session to clear it all.
  94.  
  95. I am now using the plain 800x600x256 driver (I got tired of chasing
  96. help windows all over hell and gone :-( ) and the same thing happens,
  97. only it affects the whole desktop.
  98.  
  99. I may have been remiss not to report this earlier, but I think I am
  100. making up that error with raw detail. I would like to find out how to
  101. report this bug to Trident properly. Also, if helpful, I would not
  102. mind downloading Nikon to see if it can take snapshots of the
  103. corruption on both the plain and virtual displays.
  104.  
  105. andy
  106. -- 
  107. hilmera@ucs.orst.edu  Why settle for the *lesser* of evils? Cthulu 92!
  108.