home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!cs.utexas.edu!swrinde!news.dell.com!dellunix!uudell!pensoft!usenet
- From: chauvin@pencom.com (Chris Chauvin)
- Newsgroups: comp.sys.next.misc
- Subject: Re: McGill X on a Turbo (was Re: Experiences with cubX ?)
- Keywords: X
- Message-ID: <1992Aug30.215843.27844@pencom.com>
- Date: 30 Aug 92 21:58:43 GMT
- References: <BtLG5o.Fq3@watserv1.uwaterloo.ca>
- Sender: usenet@pencom.com (Usenet Psuedo User)
- Reply-To: chauvin@pencom.com (Chris Chauvin)
- Organization: Pencom Software
- Lines: 35
-
- In article <BtLG5o.Fq3@watserv1.uwaterloo.ca> bee@watarts.uwaterloo.ca (Bill E.
- Eickmeier) writes:
- > In article <1992Aug25.201428.14395@trlabs.CA> macg@trlabs.CA (Mike MacGregor)
- writes:
- > >
- > >I'd like to get X running on my Turbo (so that rules out McGill X).
- >
- > Could someone in the know explain why McGill X doesn't work on a Turbo
- > but does on a NeXTstation - what's the fundamental difference here?
- >
- > Bill
-
- Well, my guess would be that the McGill X doesn't take into account that the
- frame buffer width changed on the turbos. If you look at the "video.h" file in
- NS 3.0, you will see:
-
- #define VIDEO_MW ((dma_chip == 313)? 1152 : 1120) /* Actual pixels per
- scanline */
-
- So it looks like that a dma chip that talks to the frame buffer was changed.
- This means that 25 mHz machines have a frame buffer width of 1152 while the
- turbos have a frame buffer width equal to the visible width, 1120.
-
- I assume (I've never seen it) that when McGill X runs on the Turbos, the scan
- line accellerator (frame width) is hard coded to 1152 and everything comes out
- skewed.
-
- (BTW, don't go looking for dma_chip to be defined anywhere. It's an internal
- kernel variable.)
-
- Chris Chauvin
- Product Manager - co-Xist
- Pencom Software
- chauvin@pencom.com
- (512) 343-1111
-