Subject: Re: dt 1.1.4 on SE/30 w/ 1.2?
To: None <port-mac68k@NetBSD.ORG>
From: Dale R. LaRoe <dlaroe@lab.housing.fsu.edu>
List: port-mac68k
Date: 10/28/1996 00:02:18
On Fri, 25 Oct 1996, Denton Gentry wrote:

>   Is dt supposed to work on the 512x350 screen? The README
>   says it hasn't been tested, but comments in the rcs history
>   in grf.c imply that it should work.
> 						Denny

I'm having the same problem. The last version that worked on the SE/30s it
seems was 1.0.1, and it doesn't have sound. I tried using the code frags
that Ken Nakata recommended but I couldn't get them to work (prob. my lack
of coding, not bad advice). 

It would be nice to get dt 1.1.4 running on the SE/30. X slows the machine 
down too much for my taste.

To refresh everybody's memory, I've included what I was talking about:

From: Ken Nakata <kenn@eden.rutgers.edu>
To: Andrew Brennan <brennan@crashprone.hahnemann.edu>,
    NetBSD Mac68k <port-mac68k@NetBSD.ORG>
Subject: Re: dt on a SE/30 ?

> ... any chance this can be made to work?  I've started it once or twice
> and it causes the screen to go white and I end up rebooting (although I

Probably this problem is caused by same reason Xmacbsd.950912 on puma
doesn't work with the SE/30 internal video.  I know the bug actually
is in the kernel but I haven't been able to hunt the bug yet.

There's probably lines like this in the source:

        vaddr = mmap(fd, blah blah);
        if (vaddr == (caddr_t)-1) {
                /* failed to mmap the frame buffer */

where 'fd' is an open file descriptor of /dev/grf0 device and 'vaddr'
stands for virtual address.  Variable names may be different from
this.  If you find the code fragment, change to:

        if (ioctl(fd, GRFIOCMAP, &vaddr) == -1) {
                /* failed to map the frame buffer */
<snip>


--
dlaroe@lab.housing.fsu.edu           BAN NEANDERTHALIC CAPTAINAGE!    
		"We apologize for the inconvenience."