home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / unix / sys5 / r4 / 454 < prev    next >
Encoding:
Internet Message Format  |  1992-11-08  |  4.1 KB

  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!olivea!charnel!sifon!thunder.mcrcim.mcgill.edu!bruno
  2. From: bruno@athena.mcrcim.mcgill.edu (Bruno Hall)
  3. Newsgroups: comp.unix.sys5.r4
  4. Subject: Re: Dell issue 2.2 video
  5. Message-ID: <1992Nov7.015255.2242@thunder.mcrcim.mcgill.edu>
  6. Date: 7 Nov 92 01:52:55 GMT
  7. References: <1311@kepler1.rentec.com> <1992Nov5.071707.17297@thunder.mcrcim.mcgill.edu> <1992Nov06.035606.0617081@locus.com>
  8. Sender: news@thunder.mcrcim.mcgill.edu
  9. Organization: McGill University Broom Closet
  10. Lines: 78
  11. Nntp-Posting-Host: athena.mcrcim.mcgill.edu
  12.  
  13. peet@locus.com (J. David Peet) writes:
  14. > I (Bruno Hall) wrote:
  15. >>
  16. >>I just got myself an ATI Graphics Ultra, and am mostly pleased with
  17. >>it.  Under Dell 2.2, running Xmach at 1024x768x256, on a (very non-Dell :-)
  18. >>486-33, I'm getting 68,000 Xstones.  It's *great*.
  19. >>
  20. >>BUT I can't seem to make a native VGA DOS image under Merge.  The
  21. >>screen just blanks out, and the thing sits there.  What this means is
  22. >>that I can't access any of the non-standard VGA modes under DOS.  Same
  23. >>story on another machine (different hadrware brand).
  24. >>
  25. >>Has anyone managed to do this with a Graphics Ultra?
  26. >>
  27. >>Naturally, neither Dell nor Locus answer my mail on this topic, which
  28. >>seems strange, particulary since this card is actually supported
  29. >>by Dell, and is a name-brand item to boot. 
  30. >
  31. >Please, I did answer your mail!  My e-mail answer got damaged, and earlier
  32. >today I got e-mail from you in which you stated that you had received
  33. >a screwed up e-mail answer from me.  I was fully intending to try again
  34. >tonight after I finished my regular tasks.  Please give us a little time to
  35. >reply before flaming.  (What if I was on vacation or sick, or was somehow
  36. >prevented from using e-mail?  
  37.  
  38. Yes, I hadn't thought of that, but then I had also seen posts from you
  39. to the net both before and after I had sent you mail (and received a
  40. munged response ;-).
  41.  
  42. >A few weeks ago our e-mail and net-news
  43. >connection machine completely died (probably taking a few messages down with
  44. >it), and took a day or so to replace it and get e-mail working again, and
  45. >more than a few days to get news flowing again.)
  46.  
  47. OK OK, I agree -- I over-reacted.  Mea culpa.
  48.  
  49. >My reply is this:  Making "native" VGA DOS images only works for a few
  50. >VGA cards.  This is a known restriction.  In the future, it is intended
  51. >that more cards will be made to work, most likely involving special
  52. >code for each new card.
  53.  
  54. Sounds like a Good Thing.
  55.  
  56. >Making "native" (a.k.a. on-card-ROM) images is an inherently dangerous
  57. >thing to do (e.g. it can lock up the machine), but if it the image file
  58. >get made, then it is safe to use.  Making "standard" VGA images is
  59. >inherently SAFE, so that is the default one that is made and used.
  60.  
  61. It's strange.  I use a 'mkimg native vga d .', and the system gets the
  62. copy of the ROM just fine, but it craps out (informs me that it's
  63. making the VGA image, doesn't seek A:, changes video modes, blanks the
  64. screen, and then stops)  when trying to make the DOS image (none is
  65. created).  It doesn't take the system down, however; after switching to a vt
  66. and back, I can kill it.
  67.  
  68. It's really a pity; the Graphics Ultra is really an excellent card for X. 
  69.  
  70. >The reason it is dangerous is not due to a "bug", but due to the fact that
  71. >for the boot code in most VGA ROMs to work, we must give it more control
  72. >over the real machine than is normally done.  Thus if the boot time code
  73. >has problems because it is trying to do something that just cannot be
  74. >supported with the current version of Merge, it can hang the machine.
  75. >In several cases I know, VGA ROM boot code plays with the system timer,
  76. >which also controls the RAM refresh.  Having the RAM refresh turned off
  77. >is a very fast way to hang your machine.
  78.  
  79. So I guess I'm also in the market for SVR4.3 and the new-and-improved
  80. Merge.  :-)
  81.  
  82. I just hope that Dell doesn't go Solaris before releasing a 4.3...
  83.  
  84. Bruno
  85. -- 
  86. /\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
  87. Bruno Hall  |  VE2HUM  |  bruno@mcrcim.mcgill.edu         
  88. McGill Research Centre for Intelligent Machines - Controls Group
  89. New systems generate new problems -- Join the Flat Earth Society.
  90.